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/N4W27...