We've discussed the idea of changing the wheel file naming scheme to deal with Linux previously, but never put together a concrete proposal.
The closest we've got is the idea of allowing the platform tag to be customised in pip and perhaps bdist_wheel, and while that's good from an "enabling experimentation" perspective, it may be overkill if the primary goal is just to better support handling of Linux distros. For starters, here's the current definition of the platform tag in PEP 425: ================= The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _ . * win32 * linux_i386 * linux_x86_64 ================= Here's my proposed change: ================= The default platform tag is distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _ . If /etc/os-release [N] exists on the system, then the values in the 'ID' and 'VERSION_ID' fields are read, all hyphens - and periods . replaced with underscore _ , and the results appended to the default tag after a separating underscore." Examples: * win32 * macosx_10_6_intel * linux_x86_64_fedora_20 * linux_x86_64_rhel_7_0 * linux_x86_64_debian_7_0 * linux_x86_64_ubuntu_14_04 ================= The [N] reference would then be a reference to http://www.freedesktop.org/software/systemd/man/os-release.html for the definition of the format of os-release. (Note that while the format originated with systemd, plenty of distros have also started providing it regardless of which init system they use) Now, this slightly overspecifies on the *consumer* side. A binary wheel that works on "rhel_7_0" for example, should almost certainly work on "rhel_7_1". However, that can be addressed on the tooling side (e.g. permitting the specification of "additional compatible platforms" when invoking pip), rather than needing to be in the specification. This also won't help with older Linux distros that don't offer /etc/os-release, but I'm OK with that - those can just continue to show up as "linux_x86_64", and PyPI can continue to disallow those uploads. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
