Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip is affected by wheel stripping PEP-508 markers #4614

Closed
tlandschoff-scale opened this issue Jul 10, 2017 · 4 comments
Closed

pip is affected by wheel stripping PEP-508 markers #4614

tlandschoff-scale opened this issue Jul 10, 2017 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation C: cache Dealing with cache and files in it type: bug A confirmed bug or unintended behavior

Comments

@tlandschoff-scale
Copy link

  • Pip version: 9.0.1
  • Python version: 2.7.12
  • Operating system: Ubuntu 16.04 Xenial

Description:

Installing the attached package (actually via a private devpi repository) using pip works on the first attempt but fails on the second. This is actually a bug in wheel that we misattributed to pip. However, as only pip is called I think it inherits this bug and it should be tracked here.

What I've run:

The first installation (from local file as well as from devpi repository) works fine:

~$ pip install issue-env-markers-wheel-17.10.tar.gz 
Processing ./issue-env-markers-wheel-17.10.tar.gz
  Ignoring non-existing-package: markers 'platform_system == "Windows"' don't match your environment
Building wheels for collected packages: issue-env-markers-wheel
  Running setup.py bdist_wheel for issue-env-markers-wheel ... done
  Stored in directory: /home/torsten.landschoff/.cache/pip/wheels/27/f4/87/4d28e50c1e0bf504953031a4390c64c797afb9e53b18e6ec76
Successfully built issue-env-markers-wheel
Installing collected packages: issue-env-markers-wheel
Successfully installed issue-env-markers-wheel-17.10

But pip will automatically use the wheel that it generated itself (using python setup.py bdist_wheel) and this will fail:

~$ pip install -I ~/.cache/pip/wheels/27/f4/87/4d28e50c1e0bf504953031a4390c64c797afb9e53b18e6ec76/issue_env_markers_wheel-17.10-cp27-none-any.whl 
Processing ./.cache/pip/wheels/27/f4/87/4d28e50c1e0bf504953031a4390c64c797afb9e53b18e6ec76/issue_env_markers_wheel-17.10-cp27-none-any.whl
Collecting non-existing-package (from issue-env-markers-wheel==17.10)
  Could not find a version that satisfies the requirement non-existing-package (from issue-env-markers-wheel==17.10) (from versions: )
No matching distribution found for non-existing-package (from issue-env-markers-wheel==17.10)

The mean thing here is that it appears that pip does something wrong when caching the builds. We mistraced this at first, dropping the pip cache on our build machines as it seemed to repair this.

The next build of course failed again after one build reintroduced the package into the wheel cache.

Here is the example package I used for reproducing:

issue-env-markers-wheel-17.10.tar.gz

Upstream bug report:

The underlying problem appears to be in the wheel package:

https://bitbucket.org/pypa/wheel/issues/181/bdist_wheel-silently-discards-pep-508#comment-38120755

I think it is worthwhile to have this ticket here as a reminder and a link because wheel is much less visible than pip and I actually spent half an hour for tracing this.

@pradyunsg pradyunsg added type: bug A confirmed bug or unintended behavior C: cache Dealing with cache and files in it labels Jul 10, 2017
@tlandschoff-scale
Copy link
Author

One more note: I was just told that the time spent for getting to the root of this was also stretched by the fact that the guy who created the affected package did not have the wheel package installed.

So it worked on his machine, as pip does not build a wheel if the wheel package is missing. Our build automation uses wheels though as some of our packages take the better part of an hour to build and the manylinux approach does not work for us.

@benoit-pierre
Copy link
Member

Related: pypa/setuptools#1081

@benoit-pierre
Copy link
Member

This can be closed.

@lock
Copy link

lock bot commented Jun 1, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 1, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: cache Dealing with cache and files in it type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants