On 4 Jun, 2013, at 18:27, Chris Barker - NOAA Federal <[email protected]> wrote:
> On Tue, Jun 4, 2013 at 1:23 AM, Ronald Oussoren <[email protected]> > wrote: > >> This isn't really a problem, distutils uses labels for the set of supported >> architectures as the architecture label in binary distributions (e.g. >> pyobjc_core-2.5-py3.4-macosx-10.8-intel.egg for an egg that supports the >> 'intel' set of architectures (x86_64 and i386), see >> _osx_support.get_platform_osx in the CPython repository for the labels that >> are currently used. >> >> This is not ideal, but works good enough for now. In the long run this >> should likely be replaced by the compressed tags sets from PEP 425 (at the >> cost of a much longer file names). > > I think now may be the "long run". Maybe, at least for 3.4 (assuming that wheel support gets in the stdlib by then). > But in any case, as we were > discussing, as in theory there could be lots of possible combinations, > in practice there are only two in the wild (plus the non-universal > ones...), and probably only one we really need to keep supporting, so > simply have a canonical name for the one or two is fine. > >> A much more interesting question is which binary wheels should be considered >> when installing a package, > > indeed. > >> there a two clear ways to select binaries and both have there usecases. >> Let's say you're running on OSX 10.8 with a CPU that supports x86_64 and a >> Python installation with support for x86_64, i386 and ppc and compiled with >> support for OSX 10.4 or later ("MACOSX_DEPLOYMENT_TARGET=10.4"). When >> installing a package you can pick either: >> >> 1) a binary wheel that supports this machine (a wheel compiled with >> deployment target 10.8 with only x86_64 support) > > can you link a newer deployment target-built lib with an older > deployment-target executable? I guess so... Yes. I've used extensions with a newer deployment target than the python executable, and even the other way around should work. > >> 2) a binary wheel that supports the same systems as the Python installations > >> The former is good enough when you only want to run code on your machine, >> the latter can be needed when you want to deploy the installed binaries to >> another machine (for example because you are using py2app to create an >> application bundle that will be installed elsewhere). > > I would say that we should clearly _prefer_ a wheel that fully > supports the pyton the installer is used with. > > But I'm a bit ambivalent about what to do if there is no such wheel > found, but there is one that supports the currently running > architecture. I"m inclined to say don't install it: I'd currently prefer to only install binaries that exactly match the python installation, that's the most conservative solution, requires no changes to installation tools and is easier to reason about. > > - We build the universal binaries to support people that don't want > to know or care about such details. > > - We want to support universal binary wheels for those folks. > > - The primary reason to build binary wheels at all is to support > non-native architectures -- it's a whole lot easier to simply build > for your current machine, and homebrew and macports, and ??? support > that already. > > All that being said, I sometimes think that we should simply have a 32 > bit and 64 bit binary out there, and forget all this universal stuff! > It works OK for Windows.... For some definition of OK ;-), the registry can be fun when you're running 32 binaries on a 64-bit windows. A clear advantage of universal binaries is that you can have one set of binaries and don't have to pick which architecture gets the most obvious installation directory (e.g. /lib vs. /lib64 on a lot of Linux systems). > >>> On my system right now, I have 32bitPPC + 32bit i386 universal python, >>> running on an intel system: >>> >>> In [2]: distutils.util.get_platform() >>> Out[2]: 'macosx-10.3-i386' > >> On my machine this returns the correct value: 'macosx-10.8-intel' (binary >> supports 10.8 or later and the i386 and x86_64 architectures). I do know >> this used to return wrong values on some version of OSX when using the Apple >> installation of Python because of the way they build Python. > > This isn't an Apple build -- I'm pretty sure it's the one from > Python.org...though looking now it's only 2.7.2 -- I guess I haven't > upgraded in a while! > > now with 2.7.5: > > In [3]: distutils.util.get_platform() > Out[3]: 'macosx-10.3-fat' > > I guess "fat" means 32bit ppc + intel, deployment target 10.3 ? That's correct. > > So we may want to update distutils.util.get_platform to do a PEP 425 > name, but we've got something that could work now. That can wait until the new packaging stuff (wheels, metadata 2.0, distlib, ...) gets merged, and even then it might be nicer to keep 'fat' and 'intel' as short names. Ronald _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
