[Distutils] Platform naming standardization

[M.-A. Lemburg]

Ronald Oussoren wrote:
> 
> On 13 Jan, 2010, at 23:44, M.-A. Lemburg wrote:
> 
>> Ronald Oussoren wrote:
>>>
>>> On 13 Jan, 2010, at 18:41, M.-A. Lemburg wrote:
>>>
>>>> Ronald Oussoren wrote:
>>>>>
>>>>> On Wednesday, January 13, 2010, at 04:15PM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>>>
>>>>>>
>>>>>>> 2) On OS X, the modification to the value returned by
>>>>>>> pkg_resources.get_platform() isn't correct for fat version of Python
>>>>>>> 2.5, as detailed in setuptools issue 19.  To solve that, we're using the
>>>>>>> patch I submitted to the issue (with a couple recent changes).
>>>>>>
>>>>>> I think that using "fat" in the version string is wrong for
>>>>>> Mac OS X, since there are many ways to build fat binaries.
>>>>>>
>>>>>> Instead, the version string should include the details of
>>>>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>>>>>
>>>>> Maybe in the long run, but for now "fat" has a well-defined meaning for distutils: fat == ppc + x86_64. There is also a number of other variants, as described in the documentation for distutils.
>>>>
>>>> I think you meant: fat == ppc + i386.
>>>
>>> Thats right.
>>>>
>>>> However, it's also possible to build binaries with ppc, i386 and
>>>> x86_64 - as are shipped with Mac OS X 10.6, so "fat" is not really
>>>> well-defined and could lead to trying to install 32-bit software for
>>>> a 64-bit build of Python.
>>>
>>> "fat" is well-defined for distutils, see the definition of get_platform at <http://docs.python.org/distutils/apiref.html>. 
>>>
>>> For distutils "fat" is always a universal binary with architectures i386 and ppc, with alternate names for other variants.
>>
>> Thanks for pointing that out, however, I don't think that creating
>> aliases for combinations of various different architectures
>> is a good idea.
>>
>> It's better to make the included architectures explicit and use
>> this logic for all platforms, not just Mac OS X.
> 
> I would probably have done that, knowing what I know now.   
> 
> Hashing out the details on what combinations of architectures are valid during installation will be fun though ;-). That is, if my python says its machine is "i386,x86_64" is it then acceptable to install an "i386" binary, an "i386,x86_64" binary, and "i386,ppc, x86_64" binary?

The point is that even though your Python binary may say it's
"i386,x86_64", the version you run your application with
will either be "i386" or "x86_64" (depending on the OS environment
settings).

Now let's say you're running the "i386" version. As long as all
installed components provide the "i386" part you should be fine.
In your example all components provide the "i386" part, so all
of them can be installed.

With the aliases, this kind of detection is also possible, but
only after mapping the aliases back to the combination of included
architecture names.

In a few years, we'll probably only see "x86_64" binaries for
Mac OS, but until then, package installers will have to
be able to work out the problem of finding installable
distribution files among the available ones.

BTW: With Python 2.6, if you build using the x86_64 version of
Python, distutils will still use the "macosx-10.5-i386"
platform identifier. Should I file a bug for this ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 14 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/