[Distutils] draft PEP: manylinux2

[Nick Coghlan]

On 7 February 2018 at 19:58, Robin Becker <robin at reportlab.com> wrote:
> On 07/02/2018 05:21, Alex Walters wrote:
>> This is a really good point.  Since pip is the main interface to packages
>> for end users anyways, we can call it manylinux8675309 and it wouldn't
>> really matter to users - the name only really matters to package
>> maintainers, not users.  And because of that, manylinux2010,
>> manylinux2014,
>> etc makes more sense.  A package maintainer is expected to be more
>> educated
>> about these matters, and that naming scheme is more useful to them.
>> "Whats
>> the oldest linux system my code will run on?" is a very likely question a
>
> ........
> I dispute the fact that package maintainers should be more educated about
> these matters. The package maintainer usually knows about one or a few
> packages (in my case reportlab etc). I know very little about the
> architectures and platforms that people are using with reportlab today. Nor
> do I know (or need to know) about multiple linux distributions and what
> libraries they supported and in what year.

Aye, there will still be guidance on packaging.python.org for folks
that just want an opinionated recommendation on what binary platforms
are best to target when producing wheel files. For that scenario,
whether we call it "manylinux2" or "manylinux2010" shouldn't matter
too much (since folks will just be copying it from the recommendation,
or using a helper tool like cibuildwheel).

> I do agree that the name of the available packages shouldn't really matter.
> Provided there is information in the name that allows the requesting pip to
> decide on the appropriate package to use (or lack thereof) that should
> suffice. Is pip clever enough to decide this or will we have to rely on the
> mysterious _manylinux module?

Hmm, that question prompted me to notice a flaw in the current wording
of https://www.python.org/dev/peps/pep-0571/#platform-detection-for-installers.

The way that's currently worded suggests that
"bool(_manylinux.manylinux2010_compatible)" would be the only way to
identify whether or not a manylinux2010 wheel should be considered for
installation.

That isn't the case: installers checking for manylinux2010
compatibility should fall back to "have_compatible_glibc(2, 12)" if
there's no `_manylinux` module, or if that module doesn't include a
"_manylinux.manylinux2010_compatible" attribute.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia