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

[Paul Moore]

On 25 September 2012 22:08, Daniel Holth <dholth at gmail.com> wrote:
> 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.

I think that this is fine, but the PEP needs to be explicit. If it's a
user option, the PEP should say "installers should allow the user to
specify the list of compatibility tags, and the default should be
XXX". If it's static, the PEP should say what it is.

Having different installers make different, incompatible assumptions,
is unpleasant. At present, of course, the only 2 real contenders are
the reference wheel implementation and pip. Others like
distutils2/packaging may follow.

[...]

>> 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.

The PEP should stick to defining behaviour for things that do exist.
Let those who build clever new options like that work out how to
integrate with this PEP. (On which note, is the "stable ABI" real yet?
On Windows, at least, it talks about a python3.dll, and yet there is
no such thing distributed with Python 3.3, so based on that (what's
the situation on Linux?) I'd be inclined to say that as of this point,
even the stable ABI can be ignored.

Paul.