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" >>>>>> <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
