On 25 September 2012 22:08, Daniel Holth
I don't think the exact order of the less-preferred options is critical, as long as you can make up your mind about whether you prefer packages with or without the C extension. Your Python is not likely to be compatible with competing py34 and cp32 wheels for the same version of a distribution. Most distributions will use either the cpXX style or the pyXX style tags, but not both.
On this basis, implementations should *not* declare none-any combinations, as they can be automatically deduced.
+0. algorithmically at least. It would not be wrong to dial down the "previous versions" logic quite a bit, too, as far as only doing cp33, cp3, py33, py3 which would mean "only use packages that are for our Python or explicitly cross-version".
One minor question on this, though, is the statement in the PEP "A user could instruct their installer to fall back to building from an sdist more or less often by configuring this list of tags". I don't see what this means - it should probably be either clarified or omitted.
In the above "fewer old tags by default" case, if you are on Python 3.3 and don't install cp32 by default, you could say "also install cp32 for this one package that I know works" by adding the cp32 tag to the list. This is to be compatible with lazy human packagers. Similarly when you are a version behind you will sometimes need to install packages built for the next version of Python.
Or you could remove all binary package tags of the form *-abi3-linux_x86_64 from the list that your installer uses to consider whether to download a built package or an sdist from pypi. It would still download built pure-Python packages.
This isn't particularly a criticism of the PEP, it's just that the wording tends to obfuscate the essentials by hinting at complexities that don't really exist in practice. For example, given the above, the only really meaningful compressed tagset I can imagine is py2.py3-none-any. Apart from this one use case, which admittedly is important, the whole compressed tagset capability is unlikely to ever be needed.
Who knows. I imagined bundling a windows and a Linux dll in a single built package, or doing something with OS X fat binaries. If the shared library has the same __pycache__/name.tag.so style naming then this feature gets more interesting, if not difficult to package.
It doesn't currently exist in practice.