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

[Daniel Holth]

On Wed, Sep 19, 2012 at 2:40 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Daniel Holth wrote:
>> On Mon, Sep 17, 2012 at 8:39 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>> Daniel Holth wrote:
>>>>>> Platform Tag
>>>>>> ------------
>>>>>>
>>>>>> The platform tag is simply `distutils.util.get_platform()` with all
>>>>>> hyphens `-` and periods `.` replaced with underscore `_`.
>>>>>
>>>>> This part is going to cause problems. distutils is good at identifying
>>>>> Linux and Windows and giving them sensible platform names, but it
>>>>> doesn't do a good job for other OSes.
>>>>
>>>> http://www.python.org/dev/peps/pep-0425/
>>>
>>> I still don't think that referencing the distutils function
>>> in the PEP is a good idea :-) It would be better to create
>>> a new helper.
>>
>> How about just sysconfig.get_platform()?
>
> That's essentially the same function :-) For some reason it's a copy
> of the one in distutils.util. I guess an oversight when sysconfig
> was created from various parts of distutils.
>
> Both functions are not suitable for the intended purpose, namely
> providing enough information to detect binary compatibility.
>
> Given that such information changes more often than we do Python
> releases and that this information is domain specific, I think it's
> better to maintain a pair of functions for creating such a platform
> string and detecting binary compatibility in a separate PyPI module
> which can then be pulled in by packaging and installer tools.
>
> The right place for the logic would be the platform module
> which was created in much the same way. Like with the above
> module, it was crowd-sourced to integrate domain specific
> knowledge. We added it to the stdlib after it stabilized.
> This is both good and bad. The good part is that it comes
> with Python automatically, the bad part that 3rd party code
> relying on it now has to deal with several different versions
> (for each Python release) and that platform changes are difficult
> to get into the module.
>
> This is why I think the PEP should just reference such a new
> module and leave the string format and binary compatibility
> check details to the module, rather than spell it out in the
> PEP.

The current implementation is at https://bitbucket.org/dholth/wheel

In wheel/bdist_wheel.py and wheel/util.py