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@twistedmatrix.com