Re: [Wheel-builders] PEP 571 - manylinux2
On Sat, Feb 10, 2018 at 12:09:32AM +1000, Nick Coghlan wrote: > On 8 February 2018 at 18:01, Mark Williams wrote: > > Highlights from the distutils-sig thread and pypa/manylinux PR so far: > > > > - Should `manylinux` use CalVer (http://calver.org) ? > > Just noting a subtlety of the CalVer suggestion so folks don't need to > dig it out of the distutils-sig threads: the proposal is to switch > from sequential numbering to instead using the approximate release > year of the library versions specified in the manylinux baseline > (*not* the year when we happen to define any given manylinux variant). > > So if manylinux1 had been versioned that way, it would likely have > been either manylinux2006 (based on when glibc 2.5 was released) or > manylinux2007 (based on when RHEL 5 was released). > > For PEP 571, the primary marker version is glibc 2.12, and the > reference distro is RHEL(/CentOS 6, giving a proposed variant name of > manylinux2010 (since both glibc 2.12 and RHEL 6.0 were released that > year). > > We don't expect this to make much difference for end users (since this > should all be a hidden implementation detail of their package > installer no matter what versioning scheme we use), but for publishers > and tool developers, including the year gives a quick and convenient > reminder of the general vintage of each target baseline. Duplicating my response to the CalVer part of the distutils-sig thread here: I'm convinced we should use CalVer. I'm still skeptical of the utility of CalVer here. Debian 6.0 (squeeze), for example, was released in 2011 but is incompatible with `manylinux2010` wheels because it uses glibc 2.11. I'm concerned that the sooner `manylinux2015` is defined, the more likely it is to describe too fuzzy an ABI era for CalVer to convey meaningful information to the LTS audience. What makes it worth it is the ability to skip and backfill versions. As you you pointed out, it would be a strange version scheme that had an architecture that gained wide support in 2015 become `manylinux3` and one that gained wide support in 2014 `manylinux4`. In particular, Geoffrey Thomas pointed out that it should be possible to produce nearly-`manylinux1` compliant wheels with a much newer toolchain: https://mail.python.org/pipermail/wheel-builders/2017-July/000283.html We may decide that an update to `manylinux1` is worthwhile, and by switching to CalVer, backfilling that version as `manylinux2008` would be straight forward. -- Mark Williams m...@twistedmatrix.com ___ Wheel-builders mailing list Wheel-builders@python.org https://mail.python.org/mailman/listinfo/wheel-builders
Re: [Wheel-builders] PEP 571 - manylinux2
On 8 February 2018 at 18:01, Mark Williams wrote: > Highlights from the distutils-sig thread and pypa/manylinux PR so far: > > - Should `manylinux` use CalVer (http://calver.org) ? Just noting a subtlety of the CalVer suggestion so folks don't need to dig it out of the distutils-sig threads: the proposal is to switch from sequential numbering to instead using the approximate release year of the library versions specified in the manylinux baseline (*not* the year when we happen to define any given manylinux variant). So if manylinux1 had been versioned that way, it would likely have been either manylinux2006 (based on when glibc 2.5 was released) or manylinux2007 (based on when RHEL 5 was released). For PEP 571, the primary marker version is glibc 2.12, and the reference distro is RHEL(/CentOS 6, giving a proposed variant name of manylinux2010 (since both glibc 2.12 and RHEL 6.0 were released that year). We don't expect this to make much difference for end users (since this should all be a hidden implementation detail of their package installer no matter what versioning scheme we use), but for publishers and tool developers, including the year gives a quick and convenient reminder of the general vintage of each target baseline. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Wheel-builders mailing list Wheel-builders@python.org https://mail.python.org/mailman/listinfo/wheel-builders
[Wheel-builders] PEP 571 - manylinux2
Hello, wheel builders! I had a chat with Geoffrey Thomas about the particulars of symbol versioning and he reminded me that you all would be interested in a successor to manylinux1. Here's the PEP so far: https://github.com/python/peps/blob/master/pep-0571.rst And the associated distutils-sig thread: https://mail.python.org/pipermail/distutils-sig/2018-February/031944.html (note I sent the first email twice from two different addresses :( The text of the PEP is the same, so you only have to read one!) And here are the PRs: https://github.com/pypa/manylinux/pull/152 https://github.com/pypa/auditwheel/pull/88 https://github.com/pypa/pip/pull/5008 I put initial Docker images up here if you'd like to repair a wheel or two: https://hub.docker.com/r/markrwilliams/manylinux2/ Highlights from the distutils-sig thread and pypa/manylinux PR so far: - Should `manylinux` use CalVer (http://calver.org) ? - Can the next `manylinux` use newer compilers than `manylinux1` without implying backwards incompatibilities? (The answer is yes - explanation forthcoming, thanks to Geoffrey for the help!) - Should the next `manylinux` drop support for i686? Please feel free to join the discussion on distutils-sig or comment on the various PRs. I look forward to collaborating with everybody! -- Mark Williams m...@twistedmatrix.com ___ Wheel-builders mailing list Wheel-builders@python.org https://mail.python.org/mailman/listinfo/wheel-builders
