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

[Paul Moore]

On 9 September 2012 13:16, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Sep 9, 2012 at 1:41 PM, Daniel Holth <dholth at gmail.com> wrote:
>> Re: http://www.python.org/dev/peps/pep-0425/ "Compatibility tags for
>> built distributions"
>>
>> Progress towards a proper set of rules for generating the tags a
>> Python implementation is likely to support.
>>
>> This system of being willing to install older built distributions is
>> intended to solve the frustrating problem with eggs that you would
>> have to build a new egg for each Python release, even for a
>> pure-Python egg that probably runs fine on a newer Python.
>
> Yep, those rules look sensible to me (and thanks for clarifying the
> intended semantics of the "py2" and "py3" version markers)

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]

On this basis, implementations should *not* declare none-any
combinations, as they can be automatically deduced.

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.

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.

Paul.