[Distutils] Platform naming standardization
mal at egenix.com
Mon Jan 18 16:44:58 CET 2010
Ronald Oussoren wrote:
> ["fat" binaries on Mac OS X]
>>>> 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
>> 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.
A package manager should of course try to install the best match
per default and best match should probably mean: use the binary
that supports all architecture parts supported by the currently
running Python binary.
However, it is well possible that some binary packages do not
come in all combinations supported by the Python binary, but do
come in the variant currently running. In such a case, the
user should still be able to install the binary package - perhaps
with a warning that the installed version won't run on some other
With the current aliasing of architecture combinations this
won't be possible, so the user won't be able to install an
ppc/i386 egg, even if she only ever uses the i386 part of a
ppc/i386/x64_86 Python binary.
Professional Python Services directly from the Source (#1, Jan 18 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
More information about the Distutils-SIG