[Python-Dev] Python 2.7 patch levels turning two digit

[Ned Deily]

In article <14DE41E2-5314-4E49-BE93-85EEEDDDEEAD at stufft.io>,
 Donald Stufft <donald at stufft.io> wrote:

> On Jun 23, 2014, at 4:31 PM, Martin v. Lowis <martin at v.loewis.de> wrote:
> 
> >> 
> >> Would that mitigate the pain, assuming that 
> >> Steve (or someone else) would be willing to build the additional 
> >> installers for the transition period?  I've done something similar on a 
> >> smaller scale with the OS X 32-bit installer for 2.7.x but that impact 
> >> is much less as the audience for that installer is much smaller.
> > 
> > Well, the question really is whether precompiled extension modules
> > available from PyPI would work on both compilers. I understand that
> > for OSX, you typically don't have precompiled binaries for the extension
> > modules, so installation compiles the modules from scratch. This is
> > easier, as it can use the ABI of the Python which will be installed
> > to.
> > 
> > If you go the "parallel ABIs" route, extension authors have to provide
> > two parallel sets of packages as well. Given 32-bit and 64-bit packages,
> > this will make actually two additional packages - just as if they had
> > to support another Python version.
> 
> As far as I know, stuff on OSX is generally built for "X compiler or later"
> so binary compatibility is kept as long as you're using an "or later" but
> I could be wrong about that. Using binary packages on OSX is a much
> less frequent thing I think though since getting a working compiler toolchain
> is easier there.

Both points are generally true on OS X so, yes, binary extensions are 
much less of an issue there.  Where binary distributions on OS X are 
most used, I think, is when there are dependencies on third-party 
non-Python libraries that are not shipped by Apple with OS X.

But, yes, if we were to go down the route of two sets of installers, 
that could mean two sets of third-party packages.  I suppose there could 
potentially be some pip / wheel / possibly Distutils help by 
conditioning the platform name or other component used to generate the 
egg / wheel / and/or bdist file names on the CRT version (or compiler 
version), much as what we do today with OS X deployment target.  Again, 
I'm speculating in ignorance here.  If that were feasible, things built 
with the old toolchain could have unchanged names. And, clearly, we 
would want to keep that "n" number of releases with two sets of 
installers to be as small as possible, like 1.  While there would be a 
certain amount of unavoidable disruption for some folks, others *might* 
welcome the opportunity to no longer have to keep around old versions of 
the tool chain, particularly if they now could use the same tool chain 
to produce binaries for both Py2 and Py3.

-- 
 Ned Deily,
 nad at acm.org