Force the --python-tag when autobuilding wheels #3225
Conversation
|
Note: This won't remove already incorrectly built wheels from the cache, this will only make it so future wheels are (hopefully) not overly broad. |
|
Additional Note: This does not affect the output of |
dstufft
force-pushed
the
force-implementation-tag
branch
from
288ff33
to
96f490b
Compare
|
I like the idea 👍 A test would be nice ^^ |
A lot of existing tarballs will successfully build a wheel, but the wheel will be implicitly broken because they will have dynamically adjusted the install_requires inside of their setup.py. Typically this is done for things like Python version, implementation, or what OS this is being installed on. We don't consider cache directories to be OS agnostic but we do consider them to be Python version and implementation agnostic. To solve this, we'll force the cached wheel to use a more specific Python tag that includes the major version and the implementation.
dstufft
force-pushed
the
force-implementation-tag
branch
from
96f490b
to
0e240d7
Compare
|
@xavfernandez Added a test. |
|
@dstufft it might be cleaner to add a new test directly testing the installation of |
|
@xavfernandez I just did that because the tests are already slow, and I didn't think it would be massively useful to have a second test redo all the same work against just to have a different assert since the work here is non-trivial amounts of time. |
Force the --python-tag when autobuilding wheels
|
Hmm, I'd like there to be some way for wheels to opt out of this. Should I file a new issue? |
|
@rbtcollins Why? The only downside I see is that you might end up with some extraneous pure python wheels, but this doesn't have any effect on wheels that aren't pure Python. These projects can also effectively |
|
Because with python 3 binary wheels can be multi version, and AIUI we're preventing that here. So its perhaps a more broad thing: we've got a (reasonably so) conservative behaviour to avoid the crushing burden of legacy pain, but it seems reasonable to have an opt-in facility to get better behaviour. |
|
@rbtcollins So it depends on what you mean by "multi-version". Python 3 doesn't to my knowledge let you do that, the ABI tag there is for differentiating things like pymalloc vs non pymalloc I think. Looking at what tags we support in pip this is what I get on Python 3.5 on OSX: Maybe it's theoretically possible to do that, but currently it's not actually possible. That being said, you can manually share a wheel between multiple versions by using the |
|
k; efuture is a fine answer. |
|
This is a very old issue, but I'm looking at it again in the context of PEP 517 support (#5407). A general PEP 517 build backend doesn't have any supported means of specifying a Given that the original issue seems to be a result of custom code in setup.py, I think it's fair to assume that only setuptools-based projects need this, but even for those there are a couple of issues:
My inclination is to say that projects hitting this issue should use Any thoughts? @dstufft I'd particularly like your input, as you were involved in the original bug report. One possible idea that might help is if we added to PEP 517 a means for a project to declare in |
|
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
bot
added
the
auto-locked
A lot of existing tarballs will successfully build a wheel, but the wheel will be implicitly broken because they will have dynamically adjusted the install_requires inside of their
setup.py. Typically this is done for things like Python version, implementation, or what OS this is being installed on. We don't consider cache directories to be OS agnostic but we do consider them to be Python version and implementation agnostic. To solve this, we'll force the cached wheel to use a more specific Python tag that includes the major version and the implementation.Fixes #3025