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"
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/