+1 to the idea in general. Would this be an *edit* to PEP425/427/Wheel-1.0 OR new peps, and a new wheel version? As someone using cent6 daily (with no os-release file), I'm greedy for another fallback technique, but the simplicity of just using os-release makes sense. Could a published "linux_x86_64_fedora_20" wheel ever become broken just due to normal "yum update" activity on fedora_20? When? Why?
On Thu, Nov 27, 2014 at 10:03 PM, Nick Coghlan <[email protected]> wrote: > 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 | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
