Package: python-pip-whl
Version: 20.1-1
Severity: normal
This is a resubmission of #917006 and #884353 with more color. I believe
this is a Debian-specific problem, despite what the resolution of
#884353 claims.
Steps to reproduce:
$ python3 -m venv venv
$ venv/bin/pip install future
...
Building wheel for future (setup.py) ... error
ERROR: Command errored out with exit status 1:
command: /venv/bin/python3 -u -c 'import sys, setuptools, tokenize;
sys.argv[0] = '"'"'/tmp/pip-install-dosvesc9/future/setup.py'"'"';
__file__='"'"'/tmp/pip-install-dosvesc9/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/pip-wheel-tkrzl6ct
cwd: /tmp/pip-install-dosvesc9/future/
Complete output (6 lines):
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: invalid command 'bdist_wheel'
----------------------------------------
ERROR: 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.18.2
The though the package is still installed, the bdist_wheel failure is
loud and rendered in red, and makes it look as though the operation has
failed.
The problem, as described in #884353, is that `import wheel` works in
pip's context (from <venv>/share/python-wheels), but the wheel module is
not on sys.path when pip invokes `venv/bin/python setup.py bdist_wheel`.
Note that upstream pip handles the situation correctly by only trying to
invoke `bdist_wheel` if `import wheel` succeeds
https://github.com/pypa/pip/blob/ea9cb06c49c0f5dddf5c00e6770ebd5228e851e1/src/pip/_internal/utils/misc.py#L892-L901
but Debian patches make this check invalid.
This also reproduces with the example from #884353, which uses
`virtualenv --no-wheel` instead of `python -m venv`:
$ virtualenv --no-wheel venv
$ venv/bin/pip install future
...
The outcome and root cause are the same.
The fix is likely to stop packaging wheel.whl with python-pip-whl. As
far as I can tell, its only effect is to make this test wrong. The wheel
module seems never to be used by pip outside of the test. Users who want
to build wheels with pip will need to install the python3-wheel package
anyway (or `pip install wheel` inside of a venv.)
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-28-generic (SMP w/64 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages python-pip-whl depends on:
ii ca-certificates 20190110
python-pip-whl recommends no packages.
python-pip-whl suggests no packages.
-- no debconf information
