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

[Paul Moore]

On 26 September 2012 15:53, Daniel Holth <dholth at gmail.com> wrote:
> bdist_wheel is incomplete too. It should read from setup.cfg for
> advice on the tags.

I wasn't trying to imply that bdist_wheel was the reference, just that
it was the best example "in the wild" that exists at the moment. Using
setup.cfg to allow user configuration of the tags sounds reasonable.

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

debug yes. That's represented in the DLL names (a _d suffix). I'm not
sure about pymalloc. I don't know where the string "cp33dm" comes
from, this is why I think the valid values should be documented in the
PEP.

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

On Windows, imp.get_suffixes shows:

>>> imp.get_suffixes()
[('.pyd', 'rb', 3), ('.py', 'U', 1), ('.pyw', 'U', 1), ('.pyc', 'rb', 2)]

I don't have a debug build to hand to check that, but Google tells me
that Martin von Loewis said:

if sys.executable.endswith("_d.exe"):
print "Debug version"

If relying on the executable name is too unsafe, you can also look
at imp.get_suffixes(), which includes "_d.pyd" in a debug build on
Windows.

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

I don't dispute this, but I'm not sure how the PEP should reflect
this. Regardless, if distinguishing UCS2 vs UCS4 matters, the PEP
should clarify how to do so.

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

I can see that argument, but to me it makes documenting (and
understanding!) what an implementation/installer is saying when it
lists the tags it will accept quite difficult. Maybe I'm just being
dense :-)

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

I'm sorry, that doesn't make any sense to me.

Paul