On Tue, Jun 4, 2013 at 10:06 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
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).
yup.
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've got a consensus of two now -- good enough for me ;-)
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).
yeah -- I do like them, when they work...
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.
it would be best for any change to get merged around the same time as the packaging stuff -- so there is only one versin out there. But I agree, the short names are nice -- if the only place anyone would get the names is distutils, then we're fine. This is all closer that I thought was -- nice! -Chris
Ronald
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov