[Python-Dev] PEP 0404 and VS 2010

[Chris Barker]

On Thu, Nov 21, 2013 at 2:53 PM, Nick Coghlan <ncoghlan at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131121/25184227/attachment.html>