Have interfaces for platform_tag(), abi_tag(), and python_tag() for the host python

[mattip]

xref pypa/wheel#367

It would be good to have one source of truth for the canonical tags from the host python, and who better to provide it than packaging.tags. This would enable refactoring code in wheel, setuptools, and pip.

[brettcannon]

I'm a little worried about exposing the individual bits of the tags just because how they come together in the final tag triples is not obvious and easy to get wrong (i.e. I can totally see someone doing three nested for loops with those functions and thus getting the wrong outcome under CPython).

This isn't to say that I am against the idea, but proper messaging that this sort of thing is only for advanced use when building tag triples from scratch. There's also the question of what would the expected semantics be? For the platform that's pretty straight-forward (although it does need to be a sequence to accommodate macOS). But what about ABI? On CPython there's a range of values. And how interpreter? Is that to be just what the newest interpreter is, or all potential version specifiers? And if all versions, do we need to worry about how those versions tie together with the other tags?

I guess my key question is all three functions needed, or just one specifically like for the platform?

I would probably also suggest names more like e.g. host_platform() or simply platform().

[mattip]

I am not sure I understand. Is there more than one expected host_platform_tag(), host_abi_tag() and host_python_tag() for the currently running runtime?

[brettcannon]

@mattip it all depends on what you mean by e.g. "host ABI". 😉 I mean are you expecting just "cp38", or would you expect ("cp38", "abi3", "none") (or some combination thereof)? I personally would expect at least ("cp38", "abi3") since I can just add/assume "none", but the others I need to be told whether the current/host interpreter supports them.

[mattip]

I guess I can limit my request to only the platform tag, but then sysconfig.getconfig_var('EXT_SUFFIX') solves this (almost, need to trim off the so. pyd suffix), once python/cpython#22088 is resolved.

[brettcannon]

For a host platform tag API, would you expect all possibilities, e.g. all of the compatible manylinux tags? Or just the newest/latest tag?

[mattip]

Just the result of sysconfig.getconfig_var('EXT_SUFFIX') with the final suffix taken off, so that this code in wheel can go away

[brettcannon]

OK, so that's for the ABI tag, not the platform tag. I'll have to think about this, but it might need to be a sequence, but in the case of 'wheel' it could always just take the first item from that sequence.

[dnicolodi]

I am writing a tool to use Meson to build python extensions and package them into wheels. For this I am looking into the wheel definition and, judging from the wheel source code, the the most complex thing seems to be getting tags right. IIUC this bug is about moving the tag generation code from wheel (which does not have a public Python API) to the packaging package (which has one). I think this would make a lot of sense, especially in the optics of PEP 517.

[brettcannon]

@dnicolodi this actually isn't about migrating the code (that happened a year ago across multiple tools). This issue is about exposing some low-level APIs in packaging.tags that currently do not exist.

[dnicolodi]

I must have expressed myself wrong, I meant that the code to compute tags could be moved from wheel to packaging. I think @mattip meant something similar:

This would enable refactoring code in wheel, setuptools, and pip.

[mattip]

Both are correct. packaging is now vendored into wheel and pip, and they use what they can. This is about creating a few more blessed functions that will allow more refactoring in wheel and pip.

[dholth]

I'm also looking for the first reasonable tag to put on a compiled wheel. As the inventor of the tagging system I assert the manylinux tags should come after the tags that your own machine can compile so that the first element of the tag list would be appropriate. Am considering using the first non-manylinux tag as a reasonable tag for a new wheel containing an extension module, like

for tag in packaging.tags.sys_tags():
....     if not 'manylinux' in str(tag):
....         print(tag)
....         break

We have also considered adding a 'local' tag instead that would always be used on the 'local' machine (for wheels that intentionally have limited distribution).