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

Use plain "abi3" where supported in pep425tags.get_supported #7327

Closed
chrahunt opened this issue Nov 10, 2019 · 0 comments · Fixed by #7367
Closed

Use plain "abi3" where supported in pep425tags.get_supported #7327

chrahunt opened this issue Nov 10, 2019 · 0 comments · Fixed by #7367
Labels
auto-locked Outdated issues that have been locked by automation state: needs discussion This needs some more discussion

Comments

@chrahunt
Copy link
Member

chrahunt commented Nov 10, 2019

What's the problem this feature will solve?

Currently we calculate stable ABI tags dynamically, when it could be static.

Recall that wheel filenames look like:

...-{python tag}-{abi tag}-{platform tag}.whl

The {abi tag} is defined in PEP 425. One specific ABI tag called out is "abi3", which is defined as "the CPython stable ABI".

Instead of just using "abi3", to get the list of stable ABIs in pep425tags.get_supported() we use this:

    for suffix in get_extension_suffixes():
        if suffix.startswith('.abi'):
            abi3s.add(suffix.split('.', 2)[1])

This seems like an attempt to apply PEP 3149 to wheel ABI tags, but seems like overkill given the only defined stable ABI is "abi3".

It would be simpler to integrate with the current packaging.tags if we just assume "abi3" is the only possible value and is available only on CPython 3.2+.

Describe the solution you'd like

if sys.implementation.name == "cpython" and sys.version_info >= (3, 2):
    abi3s.add("abi3")

or something simpler since this will only ever be the single value.

Alternative Solutions

  • Keep the current behavior and make a change in packaging.tags to support multiple user-specified stable ABIs (or to divine them in the same way we do above), and
  • Update the relevant PEPs to be more clear

Additional context

@chrahunt chrahunt added the state: needs discussion This needs some more discussion label Nov 10, 2019
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Dec 19, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Dec 19, 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 state: needs discussion This needs some more discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant