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.
Cheers,
-Barry
Attachment:
pgpBnhN6YPrc3.pgp
Description: OpenPGP digital signature