On Thu, Nov 21, 2013 at 2:53 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

For 2.7.7, I think some combination of the two following ideas would be worth pursuing:

- a C runtime independent API flag (set by default on Windows when building with a compiler other than VS2008). This would largely be a backport of some of the stable ABI work from Python 3.

very cool!

- getting Windows closer to the current Mac OS X situation by ensuring that the C runtime used directly affects the ABI flags and shared library names. PyPI would apply the Mac OS X guideline where extensions are expected to be compatible with the python.org binaries.

sounds good.

(Note, similar to the Mac OS X situation, I think we should do this without hosting any new interpreter variants on python.org -

but we do host different variants for OS-X on python.org. It's complicated by the universal binary thing, but there are two variants hosted. There are also two Windows variants  32 and 64 bit -- yes you can think of those as different platforms, but as you can run the 32 bit build on a 64 bit Windows, things do get confused -- I've seen a lot of questions on mailing lists that have to do with those two getting mixed up (the msi installer really could be smarter...)

I'm not really proposing that python.org host another varient at this point, but I dont hink it should be off the table.

VS2010 and VS2013 source builds would become separate build-from-source ecosystems for extensions, using sdists on PyPI as the default distribution mechanism)

A lot of Windows users need binaries -- it would be really nice if we could make that easy. But the key thing is that people who do a "pip install something" should not get an incompatible binary. And the way to do that is
make sure the wheel naming scheme used by binary builds in teh wild don't use the same naming scheme as pyton.org builds if they  are not compatible with them.

As it sounds like stackless is going to do this soon, it woulld be nice to have some consensus as to what the standard should be.

By the way, I'm still not sure if it should go in the ABI tag or the Platfrom tag. from the examples in the PEP, it doesn't look like it should be the ABI tab, and in the case of teh OS-X builds, it's in the platfrm tag.

Also, on my OS-X box, with a somewhat hacked ptyon,org build, I get:

pyGnome-alpha-cp27-none-macosx_10_6_i386.whl

when I build a binary wheel.

Note that the "abi" tag is "none" -- not sure why that is, this is clealy cpython2.7.* -- shouldn't that be cp27 for the ABI tag?

The wheel docs are kind of sparse, so I have no idea where that abi tag is supposed to come from -- ah, I found something in PEP 425:

"""
Why is the ABI tag (the second tag) sometimes "none" in the reference implementation?
Since Python 2 does not have an easy way to get to the SOABI (the concept comes from newer versions of Python 3) the reference implentation at the time of writing guesses "none". Ideally it would detect "py27(d|m|u)" analagous to newer versions of Python, but in the meantime "none" is a good enough way to say "don't know".
"""
I don't know what SOABI is, but it soudns like that defines what should be in the abi tag...


But the platfrom tag is:
  macosx_10_6_i386.whl

macosx -- natch'
10_6 -- built for the 10.6 SDK (I'm running 10.7...)
i386 -- I've hacked my build to be 32 bit only

Does this belong on the distutils list instead?

-Chris

--

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