[Python-modules-team] Bug#884353: --no-wheel option causes pip install errors

Robin Jarry robin.jarry at 6wind.com
Thu Dec 14 12:40:36 UTC 2017


Package: python-virtualenv
Version: 15.1.0+ds-1
Source: python-virtualenv

When creating a venv with the --no-wheel option, the wheel package is
not installed in <venv>/lib/pythonX.Y/site-packages. However, due to a
Debian patch [1], all *.whl files in /usr/share/python-wheels are copied
into <venv>/share/python-wheels. Amongst them is
/usr/share/python-wheels/wheel-0.29.0-py2.py3-none-any.whl.

[1] https://sources.debian.org/src/python-virtualenv/15.1.0+ds-1/debian/patches/use-wheels.patch/

This causes pip install errors because of the interaction with another
Debian patch [2]. This includes all <prefix>/share/python-wheels/*.whl
files into sys.path.

[2] https://sources.debian.org/src/python-pip/9.0.1-2/debian/patches/debundle.patch/

The result is that "import wheel" works in pip's context (from
<prefix>/share/python-wheels) but it does not in other python program or
lib that does not include <prefix>/share/python-wheels/*.whl in its
sys.path.

Here is how to reproduce the problem:

$ virtualenv --no-wheel ./venv
Running virtualenv with interpreter /usr/bin/python2
New python executable in ./venv/bin/python2
Also creating executable in ./venv/bin/python
Installing setuptools, pkg_resources, pip...done.
$ rm -rf ~/.cache/pip
$ ./venv/bin/pip install future
Collecting future
  Downloading future-0.16.0.tar.gz (824kB)
    100% |████████████████████████████████| 829kB 1.6MB/s
Building wheels for collected packages: future
  Running setup.py bdist_wheel for future ... error
  Complete output from command ./venv/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-OCcj3b/future/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmpTT25xXpip-wheel- --python-tag cp27:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Failed building wheel for future
  Running setup.py clean for future
Failed to build future
Installing collected packages: future
  Running setup.py install for future ... done
Successfully installed future-0.16.0

A thorough analysis reveals that when "import wheel" works here [3],
this code [4] is executed which in turn executes `./setup.py
bdist_wheel` in a subprocess [5]. Since sys.path is not preserved with
fork+exec, wheel is not available for the setup.py command which fails.

[3] https://github.com/pypa/pip/blob/9.0.1/pip/commands/install.py#L10
[4] https://github.com/pypa/pip/blob/9.0.1/pip/commands/install.py#L335
[5] https://github.com/pypa/pip/blob/9.0.1/pip/wheel.py#L710

Surprisingly, pip does not crash. It ignores the error and installs
directly from source instead. Still, this should be fixed.

I suggest that when virtualenv is executed with --no-wheel, the
wheel-*.whl file should *not* be copied into <venv>/share/python-wheels.

Here is an example patch:

---
 virtualenv.py | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/virtualenv.py b/virtualenv.py
index 61fe5448682e..ab9d9b1c2b37 100755
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -961,6 +961,12 @@ def create_environment(home_dir, site_packages=False, clear=False,
         if error.errno != errno.EEXIST:
             raise
     for project in DEBIAN_WHEEL_DEPS:
+        if no_wheel and project == 'wheel':
+            continue
         wheel_names = glob.glob(
             '/usr/share/python-wheels/{0}-*.whl'.format(project))
         if len(wheel_names) == 0:

-- 
Robin



More information about the Python-modules-team mailing list