pip: pip 9.0.1 tries to build wheels for caching even when wheel is not installed
- Pip version: 9.0.1
- Python version: 3.5
- Operating system: debian unstable
Description:
User is reporting that buildbot is not installing under python3 unless wheel package is installed: https://github.com/buildbot/buildbot/issues/3495
What I’ve run:
Here are the commands I type:
$> pyvenv buildbot-sandbox
$> cd buildbot-sandbox/
$> . bin/activate
(buildbot-sandbox) $> pip install -U pip
Requirement already up-to-date: pip in ./lib/python3.5/site-packages
(buildbot-sandbox) $> pip --version
pip 9.0.1 from .../buildbot-sandbox/lib/python3.5/site-packages (python 3.5)
(buildbot-sandbox) $> pip install 'buildbot[bundle]'
I get the packages downloaded properly, but then most of the packages are failing like this (here the future
package):
Building wheels for collected packages: future, Twisted, sqlalchemy, sqlalchemy-migrate, MarkupSafe, Tempita
Running setup.py bdist_wheel for future ... error
Complete output from command .../buildbot-sandbox/bin/python3.5 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-7r4e31_r/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/tmpdhk60rxdpip-wheel- --python-tag cp35:
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
Then, when I redo the process but I take care of installing wheel
before installing buildbot, everything is fine. Note, I simply install the wheel
package like this:
(buildbot-sandbox) $> pip install wheel
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 24 (14 by maintainers)
Hello,
after some painful digging, I may have found the root cause. This only happens with debian system packages (both virtualenv and pip).
pip has a debian patch that forces
<sys.prefix>/usr/share/python-wheels/*.whl
files to be prepended to sys.path: https://sources.debian.org/src/python-pip/9.0.1-2/debian/patches/debundle.patch/On top of that, the
--no-wheel
option for virtualenv is taken into account, but all/usr/share/python-wheels/*.whl
files are copied into<venv>/share/python-wheels
(amongst them iswheel-0.29.0-py2.py3-none-any.whl
). This is due to a debian patch: https://sources.debian.org/src/python-virtualenv/15.1.0+ds-1/debian/patches/use-wheels.patch/All this results in this import:
https://github.com/pypa/pip/blob/2743edcc77fd660fa83d47090719e050c548a497/pip/commands/install.py#L10
not failing and therefore this:
https://github.com/pypa/pip/blob/2743edcc77fd660fa83d47090719e050c548a497/pip/commands/install.py#L335
being executed.
After which, the
./setup.py bdist_wheel
command is executed in a subprocess:https://github.com/pypa/pip/blob/2743edcc77fd660fa83d47090719e050c548a497/pip/wheel.py#L713
Since
sys.path
is not inherited by subprocesses, the<venv>/share/python-wheels/wheel-0.29.0-py2.py3-none-any.whl
file is not in the python path which causes the following error:When
virtualenv --no-wheel
is specified, it should avoid copyingwheel-*.whl
to<venv>/share/python-wheels
. This also applies to--no-pip
and--no-setuptools
options.I’ll report this to debian when I have some time.
It doesn’t look like there’s anything actionable from our side here, so I will close this issue.