[Python-ideas] bdist naming scheme (compatibility tags) PEP

[Daniel Holth]

> It's worth noting that there are two somewhat independent cases:
>
> Binary built distributions (containing C extensions, typically). This
> is architecture/ABI dependent, and would generally be tagged as
> cpXX-abi-arch.
> Pure Python built distributions. This is architecture/ABI independent,
> and would be tagged as pyXX-none-any or cpXX-none-any (or maybe
> cpX-none-any or pyX-none-any).
>
> (I'm ignoring other implementations from lack of knowledge, but I
> suspect a similar distinction will be relevant).
>
> Implementations will therefore *only* match built distributions which either:
>
> 1. Exactly match implversion-abi-arch (binary built distributions).
> There's a slight complication for implementations that support
> multiple ABIs, e.g. the stable ABI, but it's minor.
> 2. Match implversion in a "fuzzy" manner if abi-arch is none-any (pure
> python built distributions). The "fuzzy" matching is clearly defined,
> as an example for CPython 3.4, try (in this order of preference) cp34
> cp3 cp33 cp32 cp31 cp30 py34 py3 py33 py32 py31 py30. [I wonder -
> should py34 be preferred over cp32? That's not what the wheel
> implementation does]

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.