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

[Daniel Holth]

> Win32 is not a good example here. As far as I know (I've experimented
> and read docs, but haven't analyzed the code), there is never a
> declared ABI on Win32. In fact, Windows is pretty much trivially
> simple:
>
> cpXY-none-win32 (for distributions with C extensions)
> pyXY-none-any (for pure-Python distributions)
>
> In fact, those two are the only values the bdist_wheel format can
> generate. Actually, for non-Windows, it's just as simple - bdist_wheel
> can only generate

bdist_wheel is incomplete too. It should read from setup.cfg for
advice on the tags.

Does win32 have debug / pymalloc builds? That is why there is a cp33dm ABI.

On linux imp.get_suffixes() includes

('.cpython-33m.so', 'rb', 3), ('.abi3.so', 'rb', 3)

and the abi tag is just an abbreviation cp33m or abi3.

> cpXY-ABI-PLAT (for distributions with C extensions)
> pyXY-none-any (for pure-Python distributions)

These are the most important, and the ones bdist_wheel can (should)
generate without configuration.

> Eggs and wininst installers, if they used this convention, would be
> the same. As would bdist_msi, as far as I know. So the question is,
> what use case is there for anything more complicated than this? The
> only possibilities I can see are:
>
> 1. The stable ABI. At the moment, I don't know how well that's
> supported - I don't think the build tools detect whether code only
> uses the stable ABI, so they assume the full ABI. Users could claim to
> use the stable ABI by manual renaming. But without an agreed and
> documented convention for the stable ABI, they can't do that, so I
> think it's premature to worry about that case. It's easy enough to add
> if needed (see below - it's just another ABI for installers to allow)
>
> 2. UCS2 vs UCS4. This is dead for Python 3.3+, so not worth
> complicating the model for.

Python 2 continues to matter. I do not and can not use Python 3 commercially.

> 4. Pure-python code which works on multiple versions of Python. This
> is a real case, and needs to be considered. Code that is (presumed)
> valid on all Python versions within the current major version can be
> manually retagged as pyX. And code that supports Python 2 and 3 can be
> retagged as py2.py3. To allow forward compatibility, installers should
> allow the user to install pyXZ code on Python version X.Y when Z<Y.
> But this should be a user option (possibly off by default) and an
> exact match should always be preferred.
>
> I'm not aware of any other cases that might matter here. The other
> implementations may well add further use cases - for example, PyPy can
> load (some) cPython code, I believe. But without details, let's wait
> to hear from them rather than speculating.

PyPy has source compatibility for some CPython extensions, so it
counts as a different ABI.

Sometimes code uses ctypes or cffi instead of the CPython ABI (or even
includes an .exe that it calls with subprocess), there was some
discussion about using the 'none' abi in that case .

> 2. An exact match wins every time. Where there are multiple ABIs, the
> best match is based on the preference order supplied.

Just let an exact match be the only kind of match. Then there is no parsing.

The implementation tag is there because packages may have different
requirements based on the implementation and version based on if:
statements in setup.py. Maybe you use cp3 or py3 when you have added
conditional requirements a-la Requries-Dist: argparse; python_version
< 2.6 in PKG-INFO?