-
Notifications
You must be signed in to change notification settings - Fork 250
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
Add packaging.tags.interpreter_abi
#610
Comments
packaging.tags.interpreter_tag
packaging.tags.interpreter_abi
So you just want the running interpreter's most strict ABI tag? Or are you after all supported ABI tags? |
Yes. In practice, this is only relevant to CPython right now, where debug builds can load both debug and non-debug modules, but we want the debug tag in that case. |
"Yes", which? Most strict or all tags? |
In any case, packaging will probably end up implementing the linked issue in order to provide a backport for currently supported python interpreters ? The question raised by @brettcannon leads me to other questions. I guess the original intent is for most specific tag in order to ease non-pure wheel building/tagging: ref python/cpython#99560 (cc @mattip) Does this means that |
I would think "most strict" would be sufficient for packaging to determine the logic for the rest of the tags, as is done in PR #611. |
Build backends that build extension modules will want to know the interpreter tag for the current interpreter.
Currently, the easiest way to achieve that is via
sys_tags
:packaging
could provide apackaging.tags.interpreter_tag
function that avoids going throughsys_tags
.The text was updated successfully, but these errors were encountered: