[Distutils] draft PEP: manylinux2

[Mark Williams]

On Mon, Feb 05, 2018 at 12:15:50PM +1000, Nick Coghlan wrote:
>
> Thanks for this!
> 
> Something we've discussed in the past is switching manylinux over to a
> variant of CalVer, where the manylinux version number inherently
> conveys the era of operating system compatibility that each variant is
> targeting. In the case of this PEP, that would be `manylinux2010`,
> since the RHEL/CentOS 6 ABI was formally set with the release of RHEL
> 6 in November 2010.
> 
> The intended benefit of that is that it would allow folks to go ahead
> and propose newer manylinux variants that allow for ppc64le and
> aarch64 support as needed, without having to guess where those
> definitions should come in a sequential series.

That seems reasonable.  I'll admit a bias towards CalVer, though :)

As a counter point: presumably a `manylinux` standard that supports
those architectures will require a PEP, in which case the author(s)
will have read the preceding `manylinx` PEPs, either to actively
borrow as much as possible or to understand arcane but necessary
details at the behest of this list.  In that case the PEPs' numbers
will determine the next `manylinux`: `manylinux1` was PEP 513; if it's
accepted, this will be PEP N > 513; and so a `manylinux` that supports
ppc64le or aarch64 will be PEP M > N.  This doesn't account for the
simultaneous proposal of independent PEPs for ppc64le and aarch64, but
in that case I imagine they'd be merged into a single PEP.

Given that `manylinux` PEP numbers determine their sequence number, I
don't see how CalVer would change the situation.

A bigger issue is that `manylinux` isn't really one dimensional.  Lots
of things happened in 2014; for example, IBM shipped the first POWER8
systems and glibc 2.19 and 2.20 were released.  But RHEL 7 and thus
CentOS ship glibc 2.17.  Why should `manylinux2014` support ppc64le
but not glibc 2.19?

Since the definition of `manylinux` depends on the state of RHEL and
CentOS, maybe we should change the sequence number to match the
underlying major release of RHEL/CentOS.  That would have `manylinux2`
become `manylinux6`, and its successor `manylinux7`.  If we require
that each `manylinux` support all the platforms its RHEL/CentOS
supports, implementers and users could simply refer to that release to
know what they're in for.

I think I'm +1 for `manylinux6`, +0 for `manylinux2010`, and -1 for
`manylinux2`, which now seems to be the worst alternative.

> Would a manylinux2 -> manylinux2010 version numbering switch
> significantly complicate implementation of the PEP?

Certainly not!  It'll take a little bit more time to adjust
`auditwheel` and `pip`, but I don't consider that to be onerous.  Once
we settle on the appropriate versioning scheme I'll be happy to update
everything!

If I may, a quick question about procedure: do I continue to included
updates to the PEP in my responses here?  Or do I link to my branch on
GitHub?

--
  Mark Williams
  mrw at twistedmatrix.com