On Sun, Jan 24, 2016 at 8:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote: [...] >> ...well, or maybe just erroring out when it sees the future and asking >> the user to help would be good enough :-). This would impose the >> requirement going forward that we'd have to wait for a pip release >> with support for manylinuxN before allowing manylinuxN onto PyPI, but >> that doesn't seem too onerous. > > For Windows and Mac OS X, dropping support for old platforms is > effectively coupled to the CPython release cycle - a Python 3.5 wheel > is less likely to work on Windows XP than a 3.3 one, for example, > since 3.5 doesn't support XP, while 3.3 does. > > We could potentially consider something similar for manylinux: scoping > the evolution of the definition by corresponding CPython release, > rather than giving it its own version number. > > So the first release of manylinux would define the ABI for Linux > wheels for 3.5 and earlier (including the 2.x series), and then 3.6 > would be the next chance to consider revising it (e.g. by bumping up > the base ABI from CentOS 5 to CentOS 6).
The problem with this is that python 2.7 is going to be supported and widely used until well past the EOL of CentOS 5, and maybe even past the EOL of CentOS 6 (in 2020). On Linux, unlike Windows, the whole system ABI underneath Python evolves in a backwards-compatible way, so there's no anchor like the MSVC CRT that's tying us to old ABIs. (And on OS X, the OS X version number is encoded as part of the platform tag, similar to the proposal for manylinux1/2/...) -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
