[Distutils] draft PEP: manylinux2

[Nick Coghlan]

On 6 February 2018 at 00:38, Ivan Pozdeev <vano at mail.mipt.ru> wrote:
> On 05.02.2018 16:51, Nick Coghlan wrote:
>> Or, we can just put the year directly in the version number, so that
>> publishers can go "I'm happy to target manylinux2010, because I'm fine
>> with users of distros that are more than 7 years old needing to
>> compile from source".
>
> The point is, a year has negative informativity in this case.
>
> The very reasoning "compatible with most distributions released since year
> <X>" is flawed 'cuz it's vague and nonintuitive.
>
> Which is "most"
> distributions? Which part of the year X? Does that mean <distribution X
> version Y> is included or not? How do I even know all that without checking
> the spec?

For most distribution decisions, that level of detail is going to be
irrelevant: what's relevant is being able to get a rough sense of how
exclusive you're being. Choosing manylinux2010 in 2018+ means "not
very exclusive", as if someone is in a sufficiently conservative
deployment environment that the base platform isn't even keeping
within 8 years of upstream development, the fact they can't use
community provided precompiled binaries is likely to be among the
least of their concerns.

By contrast, choosing manylinux2014 in 2018 *would* risk excluding
quite a few common deployment environments, since it's still in that
5-7 year window where a lot of conservative environments are
grudgingly admitting that they really do need to update their base
platform.

> (Normally, a year in an entity's name means that entity's release
> year.)

The year we happen to define any given manylinux version is pretty
close to entirely irrelevant to anything (e.g. manylinux1 was defined
in 2016, but the platform interface it describes has been available
since 2007).

The only reason the definition year isn't *completely* irrelevant is
because pip et al can only start supporting it once we define it, so
folks that aren't following our "always use a recent version of the
installation toolchain, regardless of target platform" guidance may
end up needing to care about when a particular version was defined.

> That, provided I even remember the relevant years -- since
> compatibility is governed by other things, I have absolutely no reason to.

The year informs the versions of libraries that we pick to include the
baseline: every ABI in manylinux2[010] will have been available to
distros in 2010 (when RHEL 6 was released), just as everything in
manylinux1 was around in 2007 (when RHEL 5 was released).

The fuzziness is then conveyed by the "many" in manylinux, since we do
things like assuming the use of glibc, which isn't a universally
accurate assumption (e.g. the default Alpine Linux based images
published by Docker use musl libc rather than glibc, so they don't
provide a manylinux compatible platform).

Cheers,
Nick.

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