[Distutils] draft PEP: manylinux2

Alex Walters tritium-list at sdamon.com
Sun Feb 11 10:53:05 EST 2018


Just out of curiosity, I did a little experiment.  I explained this thread
to my mother.  My mother is a wonderful woman, but she wouldn't know a byte
from a bite.  I explained it as follows:

"There is a tool that can make software run on a lot of different computers,
but only if you build it for an ancient computer.  The tool is a little
complicated - you have to learn how to get it and to use it with any
success.  The people who make it are considering changing the way they name
it.  The new naming scheme is the bare minimum year the computer running the
code can be from.  The old naming scheme is just a sequence - 1, 2, 3.
Would you be confused by the new naming scheme? Do you think people using it
would be confused?"

Her response, which I will paraphrase because my lovely mother likes four
letter words, "If it's complicated to use already, then changing the name
isn't any more confusing."

Not exactly scientific, but based on that, I don't think CalVer will be that
confusing to library developers.

> -----Original Message-----
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon.com at python.org] On Behalf Of Nick Coghlan
> Sent: Sunday, February 11, 2018 7:15 AM
> To: Mark Williams <mrw at twistedmatrix.com>
> Cc: Geoffrey Thomas <geofft at ldpreload.com>; DistUtils mailing list
> <distutils-sig at python.org>; Mark Williams <mrw at enotuniq.org>
> Subject: Re: [Distutils] draft PEP: manylinux2
> 
> On 10 February 2018 at 16:03, Mark Williams <mrw at twistedmatrix.com>
> wrote:
> > On Tue, Feb 06, 2018 at 05:55:36PM +1000, Nick Coghlan wrote:
> >> By contrast, year-based CalVer maintains distro-neutrality, while also
> >> giving a good sense of the maximum age of compatible target platforms.
> >> (e.g. given "manylinux2010", it's a pretty safe guess that Ubuntu
> >> 12.04, 14.04 and 16.04 are all expected to be compatible, while that
> >> isn't as clear given "manylinux2" or "manylinux6")
> >
> > 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.
> 
> Yeah, I'd agree with that - there's a fuzzy multi-year period from
> when libraries are available to when they become ubiquitous, so given
> a "manylinux2010", it would be surprising if a 2012 release like
> Ubuntu 12.04 didn't support it, but for distros released in 2010 or
> 2011 you'd still need to check the details. And even after that
> adoption period, there are always going to be distros that make other
> choices (like Alpine deciding glibc was too large).
> 
> > 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.
> 
> Indeed, that concrete pragmatic benefit provides a more compelling
> rationale for switching the numbering scheme.
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



More information about the Distutils-SIG mailing list