pip is affected by wheel stripping PEP-508 markers #4614
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:
But pip will automatically use the wheel that it generated itself (using
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:
Upstream bug report:
The underlying problem appears to be in the wheel package:
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.
The text was updated successfully, but these errors were encountered:
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.