Re: Idea: perennial manylinux tag

On Fri, Nov 30, 2018 at 7:13 AM Thomas Kluyver <[email protected]> wrote:
> Do we lose the ability for a system to explicitly declare that it is or isn't compatible with a given manylinux variant (via the _manylinux?

Good question.

Straw man: if _manylinux is importable, and
_manylinux.manylinux_compatible is defined, then it must be a
callable, and manylinux_compatible(<tag>) returns whether the given
tag should be considered supported.

Immediate question: should the possible return values be True/False,
or a ternary True/False/use-the-default-detection-logic?

> Presumably it would still require a new PEP, and changes to various tools, to allow manylinux wheels based around an alternative libc implementation? Is it worth naming these tags like manylinux_glibc_2_12, to anticipate that possibility? Or is that unnecessary verbosity?

In practice, the "many" in "manylinux" has always been code for
"glibc-based", so "manylinux_glibc" is kind of redundant. I guess we
could call them "linux_glibc_2_12_x86_64", but at this point python
devs seem to understand the manylinux name, so changing names would
probably cause more confusion than clarity.

I'm not sure what to think about the "2" part of the glibc version. I
think the reality is that they will never have a "3"? And if they did
we have no idea why or what it would mean? I guess we could ask them.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/[email protected]/message/UVOIB7QBK375SILVZTZIVDZRA5UTRGOU/