Re: Python package providing both modules and an app

2016-06-22 Thread Ian Cordasco
On Jun 22, 2016 7:54 PM, "Barry Warsaw"  wrote:
>
> On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>
> >This seems to be more common now that command-line invocation is
> >becoming even more discouraged. When the upstream documentation
> >recommends ‘python3 -m foo.bar’ as the primary means of invoking the
> >command line functionality, that really blurs the line between
> >command-line application versus library.
>
> Indeed.  It's true that -m invocation isn't as pretty as a /usr/bin
script,
> but it does have the advantage of unambiguously choosing the Python
version
> you want to run the script with.  How important that is depends on the
> application of course.
>
> >There is a compounding tendency to disparage ‘python3 ./foo/bar.py’,
> >which is subject to weird hacks and incomplete workarounds like
> >. I wish this trend could
> >be effectively reversed, because IMO this is a serious impediment to
> >considering Python a good choice for command-line scripting. But this is
> >all a digression, my apologies.
>
> Sorry, I don't quite understand the above.  Do you mean that you would
rather
> use `python3 ./foo/bar.py` more often and `python3 -m foo.bar` less often?
>
> In any case, thanks Hugo for choosing Python 3 as the version to use for
the
> /usr/bin script. :)

Speaking with my application developer hat on, the latter invocation
ideally helps the user be more aware of what version of Python they're
using.

This is beneficial in a couple cases:

- pip installing something: it's important for the user to know which
version of Python they're using

- running flake8 against a codebase. Flake8 relies on the version of
Python's AST for certain things. If the user is writing code with async
keywords but running Flake8 on Python 2.7, then they'll be in for a world
of unpleasantness.

By extension the same logic applies to any application that supports
multiple versions of Python but depends on things like the stdlib AST
module.

It's certainly a hideous invocation, but it has it's benefits.

Cheers,
Ian


Re: Test suite in github but missing from pypi tarballs

2016-04-21 Thread Ian Cordasco
On Thu, Apr 21, 2016 at 10:23 AM, Fred Drake  wrote:
> On Thu, Apr 21, 2016 at 10:54 AM, Tristan Seligmann
>  wrote:
>> With my upstream developer hat on: source packages on PyPI are meant for end
>> users to install via pip. They often include generated artifacts, and don't
>> include things that aren't intended for installation via pip (tests being
>> just one of these).
>
> Interesting.  In many years of working with Python (since before
> either PyPI or pip), I have a slightly different perspective.
>
> Source packages (whether on PyPI or not) with a setup.py (or whatever
> comes next) are intended for both automated or developer consumption.
> pip is just one possible tool; buildout is another, and others as
> well.

In the long history of both Python and its packaging this is
absolutely true (all you need is an archive and a setup.py) but
Python's packaging has evolved and improved for its users through
setuptools, pip, and wheel (even though I'm sure there are many on
this list who vehemently disagree). So tar files, for the *majority*
of PyPI are there to help users with ancient, barely working, versions
of pip, buildout, etc.

>> For distribution packaging purposes, the GitHub tags are generally
>> preferrable. GitHub makes archives of tagged releases available as tarballs,
>> so this is generally a simple tweak to debian/watch.
>
> I'd generally be worried if the source package doesn't closely match a
> tag in whatever VCS a project is using, but I don't think that's
> essential, release processes being what they are.

There's also a lot of data that could be in a VCS tag that is
orthogonal to what needs to be in a package for a user or
redistributor. For example, few if any people are going to want a file
that configures the (potentially closed-source) continuous integration
service(s) that the project uses and it's inconsequential to a
redistributor if a .gitignore is in the archive too. Some of this will
just needlessly inflate the package size.

> This is really independent from the debate as to whether a test suite
> should be included with the package, though.

Agreed. It's just interesting.



Joining the team

2015-12-31 Thread Ian Cordasco
Hi everyone,

I would like to join the debian-python team. I have read the policy at

  https://python-modules.alioth.debian.org/python-modules-policy.html

and accept it.

My Alioth account is sigmavirus24-guest.

I would like to join the team to help package and maintain
python-betamax (ITP
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808880) with Daniele
Tricoli.

I don't maintain any other Debian packages and I'm not part of any
other teams, but I'm eager to learn and help.

Thanks!
Ian



Re: Joining the team

2015-12-31 Thread Ian Cordasco
On Thu, Dec 31, 2015 at 11:21 AM, Scott Kitterman <deb...@kitterman.com> wrote:
> On Thursday, December 31, 2015 08:31:31 AM Ian Cordasco wrote:
>> Hi everyone,
>>
>> I would like to join the debian-python team. I have read the policy at
>>
>>   https://python-modules.alioth.debian.org/python-modules-policy.html
>>
>> and accept it.
>>
>> My Alioth account is sigmavirus24-guest.
>>
>> I would like to join the team to help package and maintain
>> python-betamax (ITP
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808880) with Daniele
>> Tricoli.
>>
>> I don't maintain any other Debian packages and I'm not part of any
>> other teams, but I'm eager to learn and help.
>>
>> Thanks!
>> Ian
>
> Welcome to the team.

Thank you!



Re: PyPI wheels (was Re: Python Policy)

2015-10-21 Thread Ian Cordasco
On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw  wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.

I'm not sure why they should prohibit binary wheel-only uploads. A
company may wish to publish a binary wheel of a tool and only that (a
wheel for Windows, OS X, different supported linux distributions,
etc.). If they do, that's their prerogative. I don't think there's
anything that says Debian (or Ubuntu) would then have to package that.

PyPI is not just there for downstream, it's there for users too
(although the usability of PyPI is not exactly ideal).



Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Ian Cordasco
On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley  wrote:
> On 2015-10-06 09:28:56 +0200 (+0200), Thomas Goirand wrote:
>> Master != kilo. It still means that I have to do all of the backport
>> work by myself.
> [...]
>> I know that it's the common assumption that, as the package maintainer
>> in Debian, I should volunteer to fix any issue in the 6+ million lines
>> of code in OpenStack ! :)
>>
>> I do try to fix things when I can. But unfortunately, this doesn't scale
>> well enough... In this particular case, it was really too much work.
>
> That is the trade-off you make by choosing to maintain as many
> packages as you do. You can obviously either spend time contributing
> stable backports upstream or time packaging software. Just accept
> that, as with Debian itself, "stable" means OpenStack upstream makes
> the bare minimum alterations necessary. This includes, in some
> cases, continuing to test the software in those branches with
> dependencies which were contemporary to the corresponding releases
> rather than chasing ever changing behavior in them. Sometimes it is
> done for expediency due to lack of interested volunteer effort, and
> sometimes out of necessity because dependencies may simply conflict
> in unresolvable ways.

And to be fair, this has been discussed many times on the mailing list
with you Thomas. The ratio of cores to stable maintenance cores is
probably something upwards of 5:1. Most of the latter group are also
members of the former group which means they have double the
responsibility (if not more, because stable maintenance is a lot more
involved than a place on the regular core reviewer team). The reality
is that stable packages relying on versions that were contemporary at
the time of their release is very very reasonable (and that's how,
e.g., stable linux distros work). After all "stable" is just the name
for "broken in ways we know about", otherwise one would call it
"perfect" for being forever in a working state under all unexpected
conditions (which no piece of software really is).



Re: managing transitions

2015-10-06 Thread Ian Cordasco
On Tue, Oct 6, 2015 at 1:11 PM, Barry Warsaw  wrote:
> On Oct 06, 2015, at 07:05 PM, Thomas Goirand wrote:
>
>>Interesting. It's the first time I hear about it, I thought it was just
>>closed source.
>
> The instance at gitlab.com is the non-free Enterprise Edition (EE).  EE has
> features we probably don't care about ayway.  The Community Edition (CE) is
> MIT/Expat.
>
>>Does it have test capabilities as well, so that we could
>>run tests on each new patch, like Gerrit does? Can we plug zuul and
>>nodepool to it?
>
> I don't know about plugging in zuul and nodepool, but the CE does have CI
> integration, which we use in the GNU Mailman project, and seems to work
> great.

It definitely can integrate with its own CI (which I believe is also
licensed similarly to GitLab CE) as well as Jenkins. Currently the
Flake8 project is hosted and developed on GitLab and uses integration
with vanilla Jenkins.



Re: I've been removed from the Python team

2015-09-30 Thread Ian Cordasco
On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue  wrote:
> On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote:
>> [Thomas Goirand, 2015-09-30]
>> > Piotr decided to remove me from the Python team.
>>
>> DPMT and PAPT to be precise, yes
>>
>> > is an over reaction and that it should be reverted.
>>
>> I talked with you many times in private about your involvement in the
>> teams over last ~3 years and since I kind of forced other admins into
>> accepting you, I also take all the blame for removing you.
>> As I said in the private mail earlier today, if you still want to work
>> with me, I'm happy to review / sponsor your commits in DPMT or help with
>> any problems you might have with tools I wrote.
>
> Dear Piotr,
>
> Even if I'm not in the team and thus I do not decide of anything, I
> wonder if that's an appropriate answer, regarding the initial trouble.
>
> We are currently talking about preventing Thomas to maintain his
> packages that has DPMT as maintainer, because he uploaded something in
> experimental, which is neither a release, nor a distro of any kind.
>
> Considering the potential trouble it'll lead to (as for an example it'll
> probably send my attempt to package mailman3 to nowhere), and the
> potential bad consequences for python team (some packages no longer
> maintained, etc), does it worth it?
>
> --
> PEB

Pierre,

I'm new to the team, mailing list, etc. (honestly, I never had a
chance to formally introduce myself to everyone) but it looks as if
Piotr has had several instances in the past where he's had to
discipline Thomas. I doubt this is an action that Piotr took lightly.
Further, I doubt those packages will suddenly go unmaintained.

Please continue working on mailman3, it will benefit the community far
more than the outcome of this apparent disciplinary action.

Cheers,
Ian



Re: Removing some python3-* packages

2015-07-09 Thread Ian Cordasco
On Jul 9, 2015 5:25 AM, Robert Collins robe...@robertcollins.net wrote:

 On 3 July 2015 at 08:29, Scott Kitterman deb...@kitterman.com wrote:

  I think dropping these duplicates is the only thing that makes sense.
For
  reference, I dropped python3-ipaddr once python3.2 was gone (because
3.3 has
  ipaddress, which does the same thing).

 Where its a dupe sure.

 unittest2, traceback2, linecache2, mock are not duplicates of the
 functionality in 3.4 - they are backports of things in 3.5 (to all
 pythons). And they will shortly have more than 3.5 itself has in it,
 as they are rolling backports: what lands in 3.6 will go into them. So
 I don't think removing them makes sense.

 I don't have a view on other packages.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud


 --
 To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
 Archive:
https://lists.debian.org/CAJ3HoZ0a9rSSAc-zv+7qhP+0n-wMGQ=hrm__togtuesopuk...@mail.gmail.com


Further, should API compatibility also be considered? If I remember
correctly ipaddress in the stdlib and ipaddr have similar but not exactly
identical APIs


Re: Removing some python3-* packages

2015-07-02 Thread Ian Cordasco
On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote:
 Barry Warsaw ba...@debian.org writes:

 […] there's actually no reason to have a Python 3 version of enum in
 any version = Python 3.4. […]

 Ian Cordasco graffatcolmin...@gmail.com writes:

 Probably a silly question, but are other libraries like unittest2 also
 being packaged for python3? Another library is mock. That was included
 in the stdlib in 3.3.

 One consideration is: What code is written to be Python 2 and Python 3
 compatible from the same code base, which achieves this by importing a
 module which is backported to Python 2?

 In some of my code I'm doing ‘import unit2’ to have features from that
 library available in Python 2 code.

 Since those features are all in Python 3's standard library, the case
 could be made that ‘python3-unit2’ is pointless; but against that is the
 fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work
 the same on both runtime versions.

 So I'd argue that ‘python3-mock’ and the like do have a place in Debian:
 they make it easier to follow the recommended strategy of having a code
 base run unchanged on Python2 and Python 3.

Just to be clear, trying to use mock on 3.4 is thoroughly broken. If
you can install python3-mock right now and use it in 3.4, then y'all
must be carrying patches to make it work. The last 3.x version that
mock works on is 3.3.

That clearly doesn't have a place on a debian with python 3.5 as the
version of python 3 included, unless you're planning on supporting
packages for python 3.3 as well that will generate a numerous amount
of bugs for you.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/can-kwu1os1+grzrbcx41jsbs2uqgwxukmw2usgmgfo4safd...@mail.gmail.com



Re: Removing some python3-* packages

2015-07-02 Thread Ian Cordasco
On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins
robe...@robertcollins.net wrote:
 On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote:
 On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au 
 wrote:
 Barry Warsaw ba...@debian.org writes:

 […] there's actually no reason to have a Python 3 version of enum in
 any version = Python 3.4. […]

 Ian Cordasco graffatcolmin...@gmail.com writes:

 Probably a silly question, but are other libraries like unittest2 also
 being packaged for python3? Another library is mock. That was included
 in the stdlib in 3.3.

 One consideration is: What code is written to be Python 2 and Python 3
 compatible from the same code base, which achieves this by importing a
 module which is backported to Python 2?

 In some of my code I'm doing ‘import unit2’ to have features from that
 library available in Python 2 code.

 Since those features are all in Python 3's standard library, the case
 could be made that ‘python3-unit2’ is pointless; but against that is the
 fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work
 the same on both runtime versions.

 So I'd argue that ‘python3-mock’ and the like do have a place in Debian:
 they make it easier to follow the recommended strategy of having a code
 base run unchanged on Python2 and Python 3.

 Just to be clear, trying to use mock on 3.4 is thoroughly broken. If
 you can install python3-mock right now and use it in 3.4, then y'all
 must be carrying patches to make it work. The last 3.x version that
 mock works on is 3.3.

 That clearly doesn't have a place on a debian with python 3.5 as the
 version of python 3 included, unless you're planning on supporting
 packages for python 3.3 as well that will generate a numerous amount
 of bugs for you.

 See my prior mail. I will be backporting all the changes in mock from
 the stdlib to the mock standalone lib in the near future.

 I have upload acls from Michael Foord for PyPI and I'm not afraid to
 use them to fix it up - if you wanted to prep a narrow patch to fix
 3.4 then please do so here - https://github.com/testing-cabal/mock

Will do in the next couple weeks. I had chatted with Michael about it
on Twitter and he expressed no interest in supporting it.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAN-Kwu1cv9BxZWb3TAte_WXe2QEkabZe8ZOd32BAL3u8=4g...@mail.gmail.com



Re: Removing some python3-* packages

2015-07-02 Thread Ian Cordasco
On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw ba...@debian.org wrote:
 As part of the 3.5 test rebuild I noticed an incompatibility with
 python3-enum, which I reported upstream.  The response was: there's actually
 no reason to have a Python 3 version of enum in any version = Python 3.4.
 Since that's all we have now, maybe it makes more sense to just remove the
 python3-enum package from Debian.

 There may be similar packages which are fairly straight backports of Python 3
 packages.  For those that are no longer necessary, what do you think about
 removing the python3-* version of the binary package?

 It seems like a bit of a regression given that we want Python 3 versions of
 our libraries, but in cases like this it probably makes sense.

 Thoughts?
 -Barry

Probably a silly question, but are other libraries like unittest2 also
being packaged for python3? Another library is mock. That was included
in the stdlib in 3.3. Is that being packaged for python3 on Debian as
well? I know it's nice to have the libraries available on both, but
mock for example stopped working on python3.4 since it's solely
maintained in the stdlib now. It doesn't make sense to package that
for both. (Keep in mind, I'm just an observer and I haven't checked if
those examples are already packaged for Py3)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAN-Kwu0t=SKW=9gH6HYGLZZNW76rvchnZVzp8Hm6C1T=ux4...@mail.gmail.com



Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

2015-05-22 Thread Ian Cordasco
On Fri, May 22, 2015 at 10:12 AM, Tristan Seligmann
mithra...@mithrandi.net wrote:
 On 22 May 2015 at 16:06, Tristan Seligmann mithra...@mithrandi.net wrote:
 Or are you saying that the ipaddress backport is not compatible with
 python3 stdlib's ipaddress? (This would be a very unfortunate state of
 affairs, but impossible to imagine)

 This should have been *not* impossible, of course.

Based purely on the fact that the current version of ipaddr is
undocumented, I would strongly be against any patch to packaged
software that causes a dependency on it for the sole purpose of
Debian's packaging of that software. You're asking the maintainers of
those packages to maintain patches for things that are undocumented.
In my opinion, Scott, if your'e so adamant about not packaging
ipaddress for Python 2, you should work with ipaddr to fix things so
maintainers can reliably maintain the software. Until that is fixed, I
think Tristan's packaging should move forward so Debian doesn't fall
too far behind pip.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAN-Kwu2fGHqo7=+qj4uox2u4h9nfxzolsnwfxgpgvsf60sf...@mail.gmail.com



Re: requests 2.7.0 in Debian experimental

2015-05-05 Thread Ian Cordasco
On Tue, May 5, 2015 at 10:01 AM, Daniele Tricoli er...@mornie.org wrote:

 Hello,

 I have uploaded version 2.7.0 of requests in experimental because it breaks
 backwards compatibility.

 I already found that httpie needs to be update to 0.9.2[¹], but I'll start
 checking all requests dependants in the following days.
 If your package has requests as dependency, and you want help me (:D),
 please
 test it with the new version and make sure all it's fine.

 My plan is to systematically check dependants before ask from the release
 team
 a transition slot for requests (this should be the proper way to handle
 this
 issue IIUC).

 Kind regards,

 [¹]

 https://github.com/jakubroztocil/httpie/blob/master/CHANGELOG.rst#092-2015-02-24

 --
  Daniele Tricoli 'Eriol'
  https://mornie.org


Thanks for being so awesome Daniele!

To elaborate on the problem with httpie: We are trying to start cleaning up
a lot of technical debt. There were constants defined in requests.compat
and httpie was relying on some of those instead of determining them for
itself/using a library like six. I checked a bunch of consumers before
removing those constants, but I missed httpie. Needless to say, we haven't
add those back since httpie released a fix very quickly.

To make it easier for everyone else, if you want to grep through the
packages you maintain for any of the symbols removed here:
https://github.com/kennethreitz/requests/commit/f37fe551bbbf6ac8d07c35c64888b4ab289c967d
it should be sufficient.

Cheers,
Ian


Re: Python 2 d-d-a proposal

2015-04-15 Thread Ian Cordasco
On Wed, Apr 15, 2015 at 3:27 PM, Paul Tagliamonte paul...@debian.org
wrote:

 Heyya d-p,

 I'd like to send an email to d-d-a asking that project to consider no
 longer creating new Debian tools in Python 2.

 I'd like this to have the endorsement of the team, so, does anyone object
 to
 me asking people to not write new tools in Python 2 only (prefer
 alternative
 deps or porting), and only use Python 2 in very special curcumstances or
 for legacy codebases (perhaps a pitch to move to Python 3), along with a
 note that we plan to deprecate Python 2 when upstream support is gone
 (2020), which puts us on track for two cycles (Buster)


 I'll make note of a team which should exist to help with such porting,
 (I'm up to help with this) that was one of the items that came out of
 the PyCon chit-chat. I got the sense from the room that this would be
 OK, but just checking if anyone here has a substantive objection.

 If not, I'll send that out later on today/tomorow.


 Thanks!
   Paul

 --
  .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
 : :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `. `'`  http://people.debian.org/~paultag
  `- http://people.debian.org/~paultag/conduct-statement.txt



Hey everyone!

I realize I haven't made a formal introduction of myself to this list (I'll
do that some other time), but I have a fairly significant amount of
experience adding Python 3 compatibility to tools while retaining Python 2
compatibility (I recently just helped SQLObject release 3.0.0a1 which is
the first version to support Python 3.4). We might want to move to making
the tools compatible first and then drop support for Python 3. Also, I'm
very much up for helping with this.

Cheers,
Ian