[Distutils] Platform naming standardization

[Ronald Oussoren]

On 14 Jan, 2010, at 10:36, M.-A. Lemburg wrote:

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

I don't agree, "easy_install somepackage" should install a component that supports at least all architectures supported by the Python binary.   Otherwise you might install a package and have problems later when you try to use it. 

An example of this is a recent 64-bit capable machine with older versions of Tkinter or wxPython:  on those systems python will run as a 64-bit binary by default, but you sometimes have to run python in 32-bit mode to be able to use Tkinter. It would be very annoying and possibly confusing when I install a library and end up not being able to use it sometimes.

I also regularly build standalone app bundles on one machine and run them on other machines, those should also included all components in all supported architectures. 

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

I agree, at least until the next new thing comes along (such as something arm-based).

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

That should be fixed in the repository, distutils assumed that the "uname -m" reflects the correct architecture and that is not true for a single-architecture build with default compiler flags on OSX 10.6.   

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100114/16f70599/attachment.bin>