On Thu, Nov 21, 2013 at 1:02 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

martin@v.loewis.de wrote:

Package authors would have to create multiple binary releases of
the same modules for Windows, and upload them to PyPI. pip would have
to learn to download the right one, depending on what build of Python
2.7 is running.

Is that much different from package authors having to
release binaries for different versions of Python,
if they want to support older versions?

or a better analogy -- both 32 and 64 bit versions -- same python version, different binary compatibility

and really exactly like the OS-X situation: one for OS-X version 10.3+ (ppc and intel32) and one for 10.6+(intel32+64).

In both cases, users need to know what they have installed, and be careful that they use a matching binary extension when they grab one.

And we are in process of having PyPi and pip do the right thing with wheels.

I think the "only" added complication is that a 64bit cpython built with VS2008 and and one built with VS2010 would look exactly the same to both the user and the linker (i.e. python27.dll would be different, but still link).

So it would be helpful if we could:

- Have a file naming scheme so people know what they are getting for both the python binary and extension binaries.

- Have a wheel naming and identifying scheme that also makes that distinction.

- Probably have a dll naming scheme that makes the distinction as well, so if the above two checks fail, users will get a clear failure at runtime, rather than a buggy success.

--

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