pip for stretch
Now that Stretch development is winding down, and I've been doing some recent maintenance on pip, I wanted to throw this out there and see if anybody has strong opinions one way or the other. I'm considering sticking with pip 8.1.2 for Stretch, even though upstream is at 9.0.1. Here's the changelog: https://pip.pypa.io/en/stable/news/ Note the backward incompatibility introduced in 9.0.0, though Donald tells me that it's not a common use case so unlikely to be a problem. pip 9 will be the default version in Python 3.6, but that probably doesn't really matter for us since python3.6 is in experimental. pip 9 does include a feature that makes it easier for upstreams to drop Python 2, by allowing them to specify a requires-python parameter. There's some better automation features and a few other things. See the changelog linked above for details. I have not started to look at what if anything needs to be done to transition to pip 9, but if you have a strong opinion one way or the other, please weigh in. Cheers, -Barry pgpQW38U_yLQf.pgp Description: OpenPGP digital signature
Re: pip for stretch
> > On Nov 21, 2016, at 6:33 PM, Barry Warsaw wrote: > > I have not started to look at what if anything needs to be done to transition > to pip 9, but if you have a strong opinion one way or the other, please weigh > in. > As one might expect, I would prefer it if folks got 9.0.1 as quickly as possible. In particular the feature that makes it easier for upstreams to drop Python 2 support is one that is really only effective when people can consider pip 9 a "minimum" version of pip to support. Getting it into the hands of folks as quickly as possible would be a big boon to that. — Donald Stufft
Re: pip for stretch
On 2016-11-21 18:33:48 -0500 (-0500), Barry Warsaw wrote: [...] > I have not started to look at what if anything needs to be done to > transition to pip 9, but if you have a strong opinion one way or > the other, please weigh in. The fix to uninstall properly when replacing with an editable install of the same package is a pretty huge one in my opinion. Ran into it quite a bit where I'd do an install from unreleased source (in editable mode because I was hacking on it) of some library, and that software was a transitive dependency of something in its own requirements list so had already been installed from an sdist/wheel without my realizing. This leads to confusingly testing the released version of the source code because it shows up first in the path when you import what you think is the code you're editing. Not a fun way to spend your time. Granted, I'm mostly running pip on unstable when developing, and I run it from a bootstrapped virtualenv anyway so don't actually use the Debian package of it other than to bootstrap my initial venv. -- Jeremy Stanley
