Also betraying the lack of knowledge of how this works, I read this section in
PEP 513 (which defines manylinux1):
> To be eligible for the manylinux1 platform tag, a Python wheel must therefore
> both (a) contain binary executables and compiled code that links only to
> libraries with SONAMEs included in the following list:
.…
libglib-2.0.so.0
Does this mean that only tags down to 2.0 needs to be generated?
TP
Sent from Mail for Windows 10
From: Brett Cannon
Sent: 01 December 2018 02:12
To: Nathaniel Smith
Cc: distutils sig
Subject: [Distutils] Re: Idea: perennial manylinux tag
I think either approach works, but if we do go with a glibc-versioned tag that
we make it explicit in the tag, e.g. `manylinux_glibc_{version}`. That way if
we ever choose to support musl (for Alpine) we can.
The one question I do have is how the compatibility tags will work for a tagged
platform? E.g. if you say manylinux_glibc_2_12 for manylinux2010, then do we
generate from 2.12 down to 1.0 (or whatever the floor is for manylinux1)? This
would match how compatibility tags work on macOS where you go from your macOS
version all the way down to the first version supporting your CPU architecture.
And just to double-check, I'm assuming we don't want to just jump straight to
distro tags and say if you're centos_6 compatible then you're fine? I assume
that would potentially over-reach on compatibility in terms of what might be
dynamically-linked against, but I thought I would ask because otherwise the
glibc-tagged platform will be a unique hybrid of macOS + not an actual OS
restriction.
On Fri, 30 Nov 2018 at 00:10, Nathaniel Smith <n...@pobox.com> wrote:
Hi all,
The manylinux1 -> manylinux2010 transition has turned out to be very difficult.
Timeline so far:
March 2017: CentOS 5 went EOL
April 2018: PEP 517 accepted
May 2018: support for manylinux2010 lands in warehouse
November 2018: support lands in auditwheel, and pip master
December 2018: 21 months after CentOS 5 EOL, wwee still don't have an official
build environment, or support in a pip release
We'll get through this, but it's been super painful and maybe we can change
things somehow so it will suck less next time.
We don't have anything like this pain on Windows or macOS. We never have to
update pip, warehouse, etc., after those OSes hit EOLs. Why not?
On Windows, we have just two tags: "win32" and "win_amd64". These are defined
to mean something like "this wheel will run on any recent-ish Windows system".
So the meaning of the tag actually changes over time: it used to be that if a
wheel said it ran on win32, then that meant it would work on winxp, but since
winxp hit EOL people started uploading "win32" wheels that don't work on winxp,
and that's worked fine.
On macOS, the tags look like "macosx_10_9_x86_64". So here we have the OS
version embedded in the tag. This means that we do occasionally switch which
tags we're using, kind of like how manylinux1 -> manylinux2010 is intended to
work. But, unlike for the manylinux tags, defining a new macosx tag is totally
trivial: every time a new OS version is released, the tag springs into
existence without any human intervention. Warehouse already accepts uploads
with this tag; pip already knows which systems can install wheels with this
tag, etc.
Can we take any inspiration from this for manylinux?
We could do the Windows thing, and have a plain "manylinux" tag that means "any
recent-ish glibc-based Linux". Today it would be defined to be "any distro
newer than CentOS 6". When CentOS 6 goes out of service, we could tweak the
definition to be "any distro newer than CentOS 7". Most parts of the toolchain
wouldn't need to be updated, though, because the tag wouldn't change, and by
assumption, enforcement wouldn't really be needed, because the only people who
could break would be ones running on unsupported platforms. Just like happens
on Windows.
We could do the macOS thing, and have a "manylinux_${glibc version}" tag that
means "this package works on any Linux using glibc newer than ${glibc
version}". We're already using this as our heuristic to handle the current
manylinux profiles, so e.g. manylinux1 is effectively equivalent to
manylinux_2_5, and manylinux2010 will be equivalent to manylinux_2_12. That way
we'd define the manylinux tags once, get support into pip and warehouse and
auditwheel once, and then in the future the only thing that would have to
change to support new distro releases or new architectures would be to set up a
proper build environment.
What do y'all think?
-n
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/6AFS4HKX6PVAS76EQNI7JNTGZZRHQ6SQ/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/HNJGCU2ALVAYHTBZYYCU2Z5ROSOVJSLQ/
