On Fri, Nov 30, 2018 at 7:13 AM Thomas Kluyver <thomas@kluyver.me.uk> 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