FYI, I've started a discussion on the next manylinux spec here: https://discuss.python.org/t/the-next-manylinux-specification/

On Thu, Dec 6, 2018 at 4:21 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
On Tue, 4 Dec 2018 at 23:51, Matthias Klose <doko@ubuntu.com> wrote:
> On 30.11.18 19:10, Brett Cannon wrote:
> > 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.
>
> while a distro tag might be overkill, just encoding glibc might not be enough.

Right, the kinds of issues you mention are why I think it's important
to keep the "many" qualifier in the name (since there are additional
constraints beyond just the glibc version), and why *something* still
needs to define what those additional constraints actually are (even
if that something becomes "the manylinux build environment project"
rather than "distutils-sig via the PEP process").

The only aspect this proposal would change is making it possible to
infer the platform compatibility checking *heuristic* from the wheel
name, rather than needing a lookup table. Installers that wanted a
more robust heuristic could still add extra checks based on the actual
linking constraints defined by the reference build environment.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-leave@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/N4W27YGBMXWWMWVDGYQXZWXBIQ7ZZENE/