Den lör 1 dec. 2018 kl 09:41 skrev Nathaniel Smith <njs@pobox.com>:
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.
As a Linux Python dev, even if I've sort of learned what "manylinux" means (not least of all from following these discussions :p), I would much prefer the "linux_glibc_2_12_x86_64" style tag. It's nice and explicit and conveys some info, and sort of follows the same style as the macOS ones. Just my 2 cents. Elvis
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 -- 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/UVOIB...