On Wednesday, February 25, 2015 04:37:53 PM Barry Warsaw wrote:
> Debian bug #744145 (Ubuntu LP: #1363642) describes this failure:
>
> $ pip install --user --upgrade requests
> $ pip install --user --upgrade mistunes
>
> (well, any package will have the same effect for step #2)
>
> Quick recap: upstream pip vendorizes (bundles) a bunch of its dependencies.
> This violates Debian Policy, so we implemented a change where these
> dependencies are also built as wheel (.whl) files. The corresponding -whl
> packages are dependencies of python{,3}-pip and get installed into
> /usr/share/python-wheels.
>
> When we create a virtual environment with either pyvenv (Python 3) or
> python-virtualenv (Python 2 or 3), these wheels get copied into the venv and
> pip gets modified so that these are put at the beginning of sys.path. Thus
> when pip itself goes to import requests, it finds the wheel version, not
> whatever other version exists later on sys.path.
>
> This works great. If you're in a venv and you upgrade requests, your venv
> will get the new version of requests, but even if this breaks the API that
> pip expects, pip will continue to work because it finds the known-good
> version in the wheel.
>
> Bug #744145 comes about because it's being invoked *outside* of the venv,
> installing packages into ~/.local/lib/python2.7/site-packages. Upgrading
> requests in this scenario places the new version of requests, with its
> incompatible API, earlier in sys.path than any other version. The
> fundamental bug is that we only put the .whl files on pip's sys.path when
> we're in a venv *not* when we're outside of one.
>
> I guess the clarity of time makes it obvious to me that those .whls should
> be put on pip's sys.path regardless of whether we're inside or outside a
> venv. If we're using the system pip, we should be using the system wheels.
> The only inside/outside difference is where those wheels live.
>
> I just committed this fix for the problem:
>
> http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=31916
>
> and tested it on sid outside a venv with pip --user. I also tested it
> inside a venv, with all of virtualenv for Python 2 and 3, and pyvenv for
> Python 3. All of these seem to work as expected, and the commands at the
> top of this message no longer fail.
>
> I have two, um, requests:
>
> * Can you please sanity check the change, and test the resulting packages,
> in whatever scenarios you can think of? I'd hate to have missed something
> obvious and introduce a regression.
>
> * What are your thoughts on reclassifying #744145 to severity grave and
> uploading a fix for this to Jessie? I'd hate to release Jessie with a
> known bug that breaks people's environments when the fix is (apparently)
> simple.
I'm confused. Having re-read the bug, I don't see how this is anything other
than user error in Debian. As I read it, your proposed solution is directly
contradictory to what we wrote about .whil files in our Python policy:
A very limited set of wheel packages are available in the archive,
but these support the narrow purpose of providing the Python 3
built-in virtual environment creation executable
pyvenv-3.X, as well as the within-venv pip
executable, in a Debian policy compliant way. The set of packages
providing wheels for this purpose are (by source package name):
chardet, distlib, html5lib, python-colorama, python-pip,
python-setuptools, python-urllib3, requests, and six.
I don't see anywhere where use of the .whl packages was envisioned outside the
venv.
If there is a bug here, I don't think using .whls at the system level (outside
of venv) is the right answer.
Scott KAttachment:
signature.asc
Description: This is a digitally signed message part.