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

More flexibility about tags when shipping binaries #175

Closed
agronholm opened this issue Oct 22, 2016 · 6 comments
Closed

More flexibility about tags when shipping binaries #175

agronholm opened this issue Oct 22, 2016 · 6 comments

Comments

@agronholm
Copy link
Contributor

Originally reported by: Armin Ronacher (Bitbucket: mitsuhiko, GitHub: mitsuhiko)


Currently there are a few situations that I would like to generate tags for but I can't.

In particular I have the following setups I care about:

  • 2.x/3.x universal wheels that ship native extensions not linked against libpython and thus python version independent
  • 2.x or 3.x specific wheels without abi identifier because not linking against libpython

This is from what I can tell not possible without monkey patching. Currently I'm doing this:

if bdist_wheel is not None:
    class CustomBdistWheel(bdist_wheel):
        def get_tag(self):
            rv = bdist_wheel.get_tag(self)
            return ('py2.py3', 'none') + rv[2:]
    cmdclass['bdist_wheel'] = CustomBdistWheel

I was thinking of sending a pull request but I'm not sure what the cleanest way to solve this is.


@agronholm
Copy link
Contributor Author

Original comment by Daniel Holth (Bitbucket: dholth, GitHub: dholth):


In the past I've just added a flag, like the universal flag and the new py_limited_api flag. Then bdist_wheel has logic to set the flag for that category of wheel. Here's the pull request that added the py_limited_api flag.

https://bitbucket.org/pypa/wheel/pull-requests/69/add-py-limited-api-flag-to-control-abi3/diff

@agronholm
Copy link
Contributor Author

Looks like a duplicate of #161 yes?

@agronholm agronholm added this to the 1.0.0 milestone Oct 7, 2017
@agronholm
Copy link
Contributor Author

I feel this issue should be dealt with one way or another before the 1.0.0 release.

@ncoghlan
Copy link
Member

Given the --plat-tag option, it seems like the natural extension would be to also offer --abi-tag and --version-tag.

All 3 could accept the :default: special value suggested in #153 (comment) to request the standard behaviour of inferring them from the running Python.

@ncoghlan
Copy link
Member

(This could prove especially useful in combination with the new wheel pack command, since it opens the door to cross-compilation of wheel archives, where the currently running version of Python may have nothing to do with the version of Python being targeted)

@agronholm
Copy link
Contributor Author

Closing as not relevant to this project anymore as bdist_wheel is now canonically part of setuptools. Also, wheel tag can be used to manipulate the tags as needed afterwards.

@agronholm agronholm closed this as not planned Won't fix, can't repro, duplicate, stale Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants