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

Force the --python-tag when autobuilding wheels #3225

Merged
merged 1 commit into from Nov 4, 2015

Conversation

Projects
None yet
4 participants
@dstufft
Member

dstufft commented Nov 4, 2015

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

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

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.

Member

dstufft commented Nov 4, 2015

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.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

Additional Note: This does not affect the output of pip wheel <foo> either, only the automatically built wheels.

Member

dstufft commented Nov 4, 2015

Additional Note: This does not affect the output of pip wheel <foo> either, only the automatically built wheels.

@xavfernandez

This comment has been minimized.

Show comment
Hide comment
@xavfernandez

xavfernandez Nov 4, 2015

Contributor

I like the idea 👍

A test would be nice ^^

Contributor

xavfernandez commented Nov 4, 2015

I like the idea 👍

A test would be nice ^^

Force the --python-tag when autobuilding wheels
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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

@xavfernandez Added a test.

Member

dstufft commented Nov 4, 2015

@xavfernandez Added a test.

@xavfernandez

This comment has been minimized.

Show comment
Hide comment
@xavfernandez

xavfernandez Nov 4, 2015

Contributor

@dstufft it might be cleaner to add a new test directly testing the installation of upper==2.0 for example and check the created wheel instead of piggybacking on test_install_builds_wheels which already test a lot (broken wheel, etc).

Contributor

xavfernandez commented Nov 4, 2015

@dstufft it might be cleaner to add a new test directly testing the installation of upper==2.0 for example and check the created wheel instead of piggybacking on test_install_builds_wheels which already test a lot (broken wheel, etc).

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

@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.

Member

dstufft commented Nov 4, 2015

@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.

dstufft added a commit that referenced this pull request Nov 4, 2015

Merge pull request #3225 from pypa/force-implementation-tag
Force the --python-tag when autobuilding wheels

@dstufft dstufft merged commit 28f658f into develop Nov 4, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@dstufft dstufft deleted the force-implementation-tag branch Nov 4, 2015

@rbtcollins

This comment has been minimized.

Show comment
Hide comment
@rbtcollins

rbtcollins Nov 4, 2015

Contributor

Hmm, I'd like there to be some way for wheels to opt out of this. Should I file a new issue?

Contributor

rbtcollins commented Nov 4, 2015

Hmm, I'd like there to be some way for wheels to opt out of this. Should I file a new issue?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

@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 opt-in opt-out in the common case by uploading a Wheel to PyPI.

Member

dstufft commented Nov 4, 2015

@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 opt-in opt-out in the common case by uploading a Wheel to PyPI.

@rbtcollins

This comment has been minimized.

Show comment
Hide comment
@rbtcollins

rbtcollins Nov 4, 2015

Contributor

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.

Contributor

rbtcollins commented Nov 4, 2015

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.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Nov 4, 2015

Member

@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:

cp35-cp35m-macosx_10_11_x86_64
cp35-cp35m-macosx_10_11_intel
cp35-cp35m-macosx_10_11_fat64
cp35-cp35m-macosx_10_11_fat32
cp35-cp35m-macosx_10_11_universal
cp35-cp35m-macosx_10_10_x86_64
cp35-cp35m-macosx_10_10_intel
cp35-cp35m-macosx_10_10_fat64
cp35-cp35m-macosx_10_10_fat32
cp35-cp35m-macosx_10_10_universal
cp35-cp35m-macosx_10_9_x86_64
cp35-cp35m-macosx_10_9_intel
cp35-cp35m-macosx_10_9_fat64
cp35-cp35m-macosx_10_9_fat32
cp35-cp35m-macosx_10_9_universal
cp35-cp35m-macosx_10_8_x86_64
cp35-cp35m-macosx_10_8_intel
cp35-cp35m-macosx_10_8_fat64
cp35-cp35m-macosx_10_8_fat32
cp35-cp35m-macosx_10_8_universal
cp35-cp35m-macosx_10_7_x86_64
cp35-cp35m-macosx_10_7_intel
cp35-cp35m-macosx_10_7_fat64
cp35-cp35m-macosx_10_7_fat32
cp35-cp35m-macosx_10_7_universal
cp35-cp35m-macosx_10_6_x86_64
cp35-cp35m-macosx_10_6_intel
cp35-cp35m-macosx_10_6_fat64
cp35-cp35m-macosx_10_6_fat32
cp35-cp35m-macosx_10_6_universal
cp35-cp35m-macosx_10_5_x86_64
cp35-cp35m-macosx_10_5_intel
cp35-cp35m-macosx_10_5_fat64
cp35-cp35m-macosx_10_5_fat32
cp35-cp35m-macosx_10_5_universal
cp35-cp35m-macosx_10_4_x86_64
cp35-cp35m-macosx_10_4_intel
cp35-cp35m-macosx_10_4_fat64
cp35-cp35m-macosx_10_4_fat32
cp35-cp35m-macosx_10_4_universal
cp35-cp35m-macosx_10_3_x86_64
cp35-cp35m-macosx_10_3_intel
cp35-cp35m-macosx_10_3_fat64
cp35-cp35m-macosx_10_3_fat32
cp35-cp35m-macosx_10_3_universal
cp35-cp35m-macosx_10_2_x86_64
cp35-cp35m-macosx_10_2_intel
cp35-cp35m-macosx_10_2_fat64
cp35-cp35m-macosx_10_2_fat32
cp35-cp35m-macosx_10_2_universal
cp35-cp35m-macosx_10_1_x86_64
cp35-cp35m-macosx_10_1_intel
cp35-cp35m-macosx_10_1_fat64
cp35-cp35m-macosx_10_1_fat32
cp35-cp35m-macosx_10_1_universal
cp35-cp35m-macosx_10_0_x86_64
cp35-cp35m-macosx_10_0_intel
cp35-cp35m-macosx_10_0_fat64
cp35-cp35m-macosx_10_0_fat32
cp35-cp35m-macosx_10_0_universal
cp35-abi3-macosx_10_11_x86_64
cp35-abi3-macosx_10_11_intel
cp35-abi3-macosx_10_11_fat64
cp35-abi3-macosx_10_11_fat32
cp35-abi3-macosx_10_11_universal
cp35-abi3-macosx_10_10_x86_64
cp35-abi3-macosx_10_10_intel
cp35-abi3-macosx_10_10_fat64
cp35-abi3-macosx_10_10_fat32
cp35-abi3-macosx_10_10_universal
cp35-abi3-macosx_10_9_x86_64
cp35-abi3-macosx_10_9_intel
cp35-abi3-macosx_10_9_fat64
cp35-abi3-macosx_10_9_fat32
cp35-abi3-macosx_10_9_universal
cp35-abi3-macosx_10_8_x86_64
cp35-abi3-macosx_10_8_intel
cp35-abi3-macosx_10_8_fat64
cp35-abi3-macosx_10_8_fat32
cp35-abi3-macosx_10_8_universal
cp35-abi3-macosx_10_7_x86_64
cp35-abi3-macosx_10_7_intel
cp35-abi3-macosx_10_7_fat64
cp35-abi3-macosx_10_7_fat32
cp35-abi3-macosx_10_7_universal
cp35-abi3-macosx_10_6_x86_64
cp35-abi3-macosx_10_6_intel
cp35-abi3-macosx_10_6_fat64
cp35-abi3-macosx_10_6_fat32
cp35-abi3-macosx_10_6_universal
cp35-abi3-macosx_10_5_x86_64
cp35-abi3-macosx_10_5_intel
cp35-abi3-macosx_10_5_fat64
cp35-abi3-macosx_10_5_fat32
cp35-abi3-macosx_10_5_universal
cp35-abi3-macosx_10_4_x86_64
cp35-abi3-macosx_10_4_intel
cp35-abi3-macosx_10_4_fat64
cp35-abi3-macosx_10_4_fat32
cp35-abi3-macosx_10_4_universal
cp35-abi3-macosx_10_3_x86_64
cp35-abi3-macosx_10_3_intel
cp35-abi3-macosx_10_3_fat64
cp35-abi3-macosx_10_3_fat32
cp35-abi3-macosx_10_3_universal
cp35-abi3-macosx_10_2_x86_64
cp35-abi3-macosx_10_2_intel
cp35-abi3-macosx_10_2_fat64
cp35-abi3-macosx_10_2_fat32
cp35-abi3-macosx_10_2_universal
cp35-abi3-macosx_10_1_x86_64
cp35-abi3-macosx_10_1_intel
cp35-abi3-macosx_10_1_fat64
cp35-abi3-macosx_10_1_fat32
cp35-abi3-macosx_10_1_universal
cp35-abi3-macosx_10_0_x86_64
cp35-abi3-macosx_10_0_intel
cp35-abi3-macosx_10_0_fat64
cp35-abi3-macosx_10_0_fat32
cp35-abi3-macosx_10_0_universal
cp35-none-macosx_10_11_x86_64
cp35-none-macosx_10_11_intel
cp35-none-macosx_10_11_fat64
cp35-none-macosx_10_11_fat32
cp35-none-macosx_10_11_universal
cp35-none-macosx_10_10_x86_64
cp35-none-macosx_10_10_intel
cp35-none-macosx_10_10_fat64
cp35-none-macosx_10_10_fat32
cp35-none-macosx_10_10_universal
cp35-none-macosx_10_9_x86_64
cp35-none-macosx_10_9_intel
cp35-none-macosx_10_9_fat64
cp35-none-macosx_10_9_fat32
cp35-none-macosx_10_9_universal
cp35-none-macosx_10_8_x86_64
cp35-none-macosx_10_8_intel
cp35-none-macosx_10_8_fat64
cp35-none-macosx_10_8_fat32
cp35-none-macosx_10_8_universal
cp35-none-macosx_10_7_x86_64
cp35-none-macosx_10_7_intel
cp35-none-macosx_10_7_fat64
cp35-none-macosx_10_7_fat32
cp35-none-macosx_10_7_universal
cp35-none-macosx_10_6_x86_64
cp35-none-macosx_10_6_intel
cp35-none-macosx_10_6_fat64
cp35-none-macosx_10_6_fat32
cp35-none-macosx_10_6_universal
cp35-none-macosx_10_5_x86_64
cp35-none-macosx_10_5_intel
cp35-none-macosx_10_5_fat64
cp35-none-macosx_10_5_fat32
cp35-none-macosx_10_5_universal
cp35-none-macosx_10_4_x86_64
cp35-none-macosx_10_4_intel
cp35-none-macosx_10_4_fat64
cp35-none-macosx_10_4_fat32
cp35-none-macosx_10_4_universal
cp35-none-macosx_10_3_x86_64
cp35-none-macosx_10_3_intel
cp35-none-macosx_10_3_fat64
cp35-none-macosx_10_3_fat32
cp35-none-macosx_10_3_universal
cp35-none-macosx_10_2_x86_64
cp35-none-macosx_10_2_intel
cp35-none-macosx_10_2_fat64
cp35-none-macosx_10_2_fat32
cp35-none-macosx_10_2_universal
cp35-none-macosx_10_1_x86_64
cp35-none-macosx_10_1_intel
cp35-none-macosx_10_1_fat64
cp35-none-macosx_10_1_fat32
cp35-none-macosx_10_1_universal
cp35-none-macosx_10_0_x86_64
cp35-none-macosx_10_0_intel
cp35-none-macosx_10_0_fat64
cp35-none-macosx_10_0_fat32
cp35-none-macosx_10_0_universal
py3-none-macosx_10_0_universal
cp35-none-any
cp3-none-any
cp34-none-any
cp33-none-any
cp32-none-any
cp31-none-any
cp30-none-any
py35-none-any
py3-none-any
py34-none-any
py33-none-any
py32-none-any
py31-none-any
py30-none-any

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 . thing to have multiple tags associated with the wheel. That's currently doable, but is super manual right now and I don't think it is an important use case to support in the wheel cache right now.

Member

dstufft commented Nov 4, 2015

@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:

cp35-cp35m-macosx_10_11_x86_64
cp35-cp35m-macosx_10_11_intel
cp35-cp35m-macosx_10_11_fat64
cp35-cp35m-macosx_10_11_fat32
cp35-cp35m-macosx_10_11_universal
cp35-cp35m-macosx_10_10_x86_64
cp35-cp35m-macosx_10_10_intel
cp35-cp35m-macosx_10_10_fat64
cp35-cp35m-macosx_10_10_fat32
cp35-cp35m-macosx_10_10_universal
cp35-cp35m-macosx_10_9_x86_64
cp35-cp35m-macosx_10_9_intel
cp35-cp35m-macosx_10_9_fat64
cp35-cp35m-macosx_10_9_fat32
cp35-cp35m-macosx_10_9_universal
cp35-cp35m-macosx_10_8_x86_64
cp35-cp35m-macosx_10_8_intel
cp35-cp35m-macosx_10_8_fat64
cp35-cp35m-macosx_10_8_fat32
cp35-cp35m-macosx_10_8_universal
cp35-cp35m-macosx_10_7_x86_64
cp35-cp35m-macosx_10_7_intel
cp35-cp35m-macosx_10_7_fat64
cp35-cp35m-macosx_10_7_fat32
cp35-cp35m-macosx_10_7_universal
cp35-cp35m-macosx_10_6_x86_64
cp35-cp35m-macosx_10_6_intel
cp35-cp35m-macosx_10_6_fat64
cp35-cp35m-macosx_10_6_fat32
cp35-cp35m-macosx_10_6_universal
cp35-cp35m-macosx_10_5_x86_64
cp35-cp35m-macosx_10_5_intel
cp35-cp35m-macosx_10_5_fat64
cp35-cp35m-macosx_10_5_fat32
cp35-cp35m-macosx_10_5_universal
cp35-cp35m-macosx_10_4_x86_64
cp35-cp35m-macosx_10_4_intel
cp35-cp35m-macosx_10_4_fat64
cp35-cp35m-macosx_10_4_fat32
cp35-cp35m-macosx_10_4_universal
cp35-cp35m-macosx_10_3_x86_64
cp35-cp35m-macosx_10_3_intel
cp35-cp35m-macosx_10_3_fat64
cp35-cp35m-macosx_10_3_fat32
cp35-cp35m-macosx_10_3_universal
cp35-cp35m-macosx_10_2_x86_64
cp35-cp35m-macosx_10_2_intel
cp35-cp35m-macosx_10_2_fat64
cp35-cp35m-macosx_10_2_fat32
cp35-cp35m-macosx_10_2_universal
cp35-cp35m-macosx_10_1_x86_64
cp35-cp35m-macosx_10_1_intel
cp35-cp35m-macosx_10_1_fat64
cp35-cp35m-macosx_10_1_fat32
cp35-cp35m-macosx_10_1_universal
cp35-cp35m-macosx_10_0_x86_64
cp35-cp35m-macosx_10_0_intel
cp35-cp35m-macosx_10_0_fat64
cp35-cp35m-macosx_10_0_fat32
cp35-cp35m-macosx_10_0_universal
cp35-abi3-macosx_10_11_x86_64
cp35-abi3-macosx_10_11_intel
cp35-abi3-macosx_10_11_fat64
cp35-abi3-macosx_10_11_fat32
cp35-abi3-macosx_10_11_universal
cp35-abi3-macosx_10_10_x86_64
cp35-abi3-macosx_10_10_intel
cp35-abi3-macosx_10_10_fat64
cp35-abi3-macosx_10_10_fat32
cp35-abi3-macosx_10_10_universal
cp35-abi3-macosx_10_9_x86_64
cp35-abi3-macosx_10_9_intel
cp35-abi3-macosx_10_9_fat64
cp35-abi3-macosx_10_9_fat32
cp35-abi3-macosx_10_9_universal
cp35-abi3-macosx_10_8_x86_64
cp35-abi3-macosx_10_8_intel
cp35-abi3-macosx_10_8_fat64
cp35-abi3-macosx_10_8_fat32
cp35-abi3-macosx_10_8_universal
cp35-abi3-macosx_10_7_x86_64
cp35-abi3-macosx_10_7_intel
cp35-abi3-macosx_10_7_fat64
cp35-abi3-macosx_10_7_fat32
cp35-abi3-macosx_10_7_universal
cp35-abi3-macosx_10_6_x86_64
cp35-abi3-macosx_10_6_intel
cp35-abi3-macosx_10_6_fat64
cp35-abi3-macosx_10_6_fat32
cp35-abi3-macosx_10_6_universal
cp35-abi3-macosx_10_5_x86_64
cp35-abi3-macosx_10_5_intel
cp35-abi3-macosx_10_5_fat64
cp35-abi3-macosx_10_5_fat32
cp35-abi3-macosx_10_5_universal
cp35-abi3-macosx_10_4_x86_64
cp35-abi3-macosx_10_4_intel
cp35-abi3-macosx_10_4_fat64
cp35-abi3-macosx_10_4_fat32
cp35-abi3-macosx_10_4_universal
cp35-abi3-macosx_10_3_x86_64
cp35-abi3-macosx_10_3_intel
cp35-abi3-macosx_10_3_fat64
cp35-abi3-macosx_10_3_fat32
cp35-abi3-macosx_10_3_universal
cp35-abi3-macosx_10_2_x86_64
cp35-abi3-macosx_10_2_intel
cp35-abi3-macosx_10_2_fat64
cp35-abi3-macosx_10_2_fat32
cp35-abi3-macosx_10_2_universal
cp35-abi3-macosx_10_1_x86_64
cp35-abi3-macosx_10_1_intel
cp35-abi3-macosx_10_1_fat64
cp35-abi3-macosx_10_1_fat32
cp35-abi3-macosx_10_1_universal
cp35-abi3-macosx_10_0_x86_64
cp35-abi3-macosx_10_0_intel
cp35-abi3-macosx_10_0_fat64
cp35-abi3-macosx_10_0_fat32
cp35-abi3-macosx_10_0_universal
cp35-none-macosx_10_11_x86_64
cp35-none-macosx_10_11_intel
cp35-none-macosx_10_11_fat64
cp35-none-macosx_10_11_fat32
cp35-none-macosx_10_11_universal
cp35-none-macosx_10_10_x86_64
cp35-none-macosx_10_10_intel
cp35-none-macosx_10_10_fat64
cp35-none-macosx_10_10_fat32
cp35-none-macosx_10_10_universal
cp35-none-macosx_10_9_x86_64
cp35-none-macosx_10_9_intel
cp35-none-macosx_10_9_fat64
cp35-none-macosx_10_9_fat32
cp35-none-macosx_10_9_universal
cp35-none-macosx_10_8_x86_64
cp35-none-macosx_10_8_intel
cp35-none-macosx_10_8_fat64
cp35-none-macosx_10_8_fat32
cp35-none-macosx_10_8_universal
cp35-none-macosx_10_7_x86_64
cp35-none-macosx_10_7_intel
cp35-none-macosx_10_7_fat64
cp35-none-macosx_10_7_fat32
cp35-none-macosx_10_7_universal
cp35-none-macosx_10_6_x86_64
cp35-none-macosx_10_6_intel
cp35-none-macosx_10_6_fat64
cp35-none-macosx_10_6_fat32
cp35-none-macosx_10_6_universal
cp35-none-macosx_10_5_x86_64
cp35-none-macosx_10_5_intel
cp35-none-macosx_10_5_fat64
cp35-none-macosx_10_5_fat32
cp35-none-macosx_10_5_universal
cp35-none-macosx_10_4_x86_64
cp35-none-macosx_10_4_intel
cp35-none-macosx_10_4_fat64
cp35-none-macosx_10_4_fat32
cp35-none-macosx_10_4_universal
cp35-none-macosx_10_3_x86_64
cp35-none-macosx_10_3_intel
cp35-none-macosx_10_3_fat64
cp35-none-macosx_10_3_fat32
cp35-none-macosx_10_3_universal
cp35-none-macosx_10_2_x86_64
cp35-none-macosx_10_2_intel
cp35-none-macosx_10_2_fat64
cp35-none-macosx_10_2_fat32
cp35-none-macosx_10_2_universal
cp35-none-macosx_10_1_x86_64
cp35-none-macosx_10_1_intel
cp35-none-macosx_10_1_fat64
cp35-none-macosx_10_1_fat32
cp35-none-macosx_10_1_universal
cp35-none-macosx_10_0_x86_64
cp35-none-macosx_10_0_intel
cp35-none-macosx_10_0_fat64
cp35-none-macosx_10_0_fat32
cp35-none-macosx_10_0_universal
py3-none-macosx_10_0_universal
cp35-none-any
cp3-none-any
cp34-none-any
cp33-none-any
cp32-none-any
cp31-none-any
cp30-none-any
py35-none-any
py3-none-any
py34-none-any
py33-none-any
py32-none-any
py31-none-any
py30-none-any

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 . thing to have multiple tags associated with the wheel. That's currently doable, but is super manual right now and I don't think it is an important use case to support in the wheel cache right now.

@rbtcollins

This comment has been minimized.

Show comment
Hide comment
@rbtcollins

rbtcollins Nov 4, 2015

Contributor

k; efuture is a fine answer.

Contributor

rbtcollins commented Nov 4, 2015

k; efuture is a fine answer.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Jul 24, 2018

Member

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 --python-tag option (backends could support a config option on a case by case basis, but pip can't rely on that support).

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:

  1. Detecting that a project uses setuptools would need us to hard-code a check for the setuptools PEP 517 backend name in pip.
  2. The setuptools backend doesn't seem to support passing --python-tag anyway.

My inclination is to say that projects hitting this issue should use --no-build-isolation in the short term to force the legacy install path, and should be looking to fix their build process to generate validly-tagged wheels (so that when we finally remove the legacy path, they don't stop working).

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 pyproject.toml that they did not support reusing wheels, and backends must not cache wheels built when installing from sdist. That allows projects to "opt out" of wheel caching, in a backend and installer independent way. I'd be happy to look at including such an option as part of the PEP 517 implementation work, but it would ultimately need adding to the PEP. Would that be a reasonable solution?

Member

pfmoore commented Jul 24, 2018

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 --python-tag option (backends could support a config option on a case by case basis, but pip can't rely on that support).

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:

  1. Detecting that a project uses setuptools would need us to hard-code a check for the setuptools PEP 517 backend name in pip.
  2. The setuptools backend doesn't seem to support passing --python-tag anyway.

My inclination is to say that projects hitting this issue should use --no-build-isolation in the short term to force the legacy install path, and should be looking to fix their build process to generate validly-tagged wheels (so that when we finally remove the legacy path, they don't stop working).

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 pyproject.toml that they did not support reusing wheels, and backends must not cache wheels built when installing from sdist. That allows projects to "opt out" of wheel caching, in a backend and installer independent way. I'd be happy to look at including such an option as part of the PEP 517 implementation work, but it would ultimately need adding to the PEP. Would that be a reasonable solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment