It would help packaging if PEP 425 python, abi, and platform tags of the currently running python were available. For instance, in order to determine the glibc used by the running interpreter, packaging must resort to calling ld to figure out if this is musl linux or not. While the SOABI tag does have the tag information, it requires parsing in packaging in order to turn that into PEP 425-compliant tags, and even then there are issues with the SOABI for musllinux.
In short, it would be nice if sysconfig could provide the three tags. There is some discussion on a this topic in an issue in packaging, where it turns out the ABI tag might need to be a tuple of ("cp39", "abi3").
While I support this idea (for selfish reasons of greatly simplifying packaging.tags some day), this would be a slight shift for Python itself as it would now understand the concept of wheel tags natively instead of it being handled externally. But at this point I don’t think wheel tags are going anywhere, and even if there is a theoretical wheel 2 format, I don’t think the tags would be wasted, just built upon.
It would be tricky to update Python’s idea of its tags if/when we add support for new tags (like musllinux, most recently). Of course that would just mean we have to use another tool that pulls the tags from Python and then fixes them up until the changes made it upstream, which isn’t the end of the world. I’m not sure how much benefit it would give though, either.
(And unfortunately the reason musl version detection has to invoke ld.so is because there’s no way to detect musl’s version from within process. So the only way Python could figure it out would be to invoke ld.so anyway. Note you can’t use compile-time detection because we want the version of libc that’s being used at runtime, which might be different.)
I think we might need to separate this conversation into two groups: tags directly controlled by the interpreter and tags controlled by the user. For the former, the interpreter knows its interpreter and ABI compatibility, so providing those should be safe.
It’s the platform tag which is controlled by the user. We really don’t know where an interpreter may be compiled or run, so fully knowing what the platform tag should be a-priori is always going to be impossible.
But the interpreter and ABI tag? That’s entirely up to the interpreter itself and it can definitely tell us what they should be. And in this specific instance, we could give ultimate flexibility by saying the interpreter needs to provide the pairing of interpreter and ABI tags, leaving platform detection to external code that can update as necessary, tacking it on to the interpreter-ABI tags pairs (although that may complicate the logic when you need the interpreter version and want to add it to the none ABI tag).
I’m assuming interpreter-agnostic versions don’t need to be listed since that’s implicit.