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