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)

Most upvoted comments

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 is wheel-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:

error: invalid command 'bdist_wheel'

When virtualenv --no-wheel is specified, it should avoid copying wheel-*.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.