<div dir="ltr"><div><div><div>+1 to the idea in general.<br></div>Would this be an *edit* to PEP425/427/Wheel-1.0  OR new peps, and a new wheel version?<br></div>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.<br></div>Could a published "linux_x86_64_fedora_20" wheel ever become broken just due to normal "yum update" activity on fedora_20?  When? Why?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 27, 2014 at 10:03 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've discussed the idea of changing the wheel file naming scheme to<br>
deal with Linux previously, but never put together a concrete<br>
proposal.<br>
<br>
The closest we've got is the idea of allowing the platform tag to be<br>
customised in pip and perhaps bdist_wheel, and while that's good from<br>
an "enabling experimentation" perspective, it may be overkill if the<br>
primary goal is just to better support handling of Linux distros.<br>
<br>
For starters, here's the current definition of the platform tag in PEP 425:<br>
<br>
=================<br>
The platform tag is simply distutils.util.get_platform() with all<br>
hyphens - and periods . replaced with underscore _ .<br>
<br>
* win32<br>
* linux_i386<br>
* linux_x86_64<br>
=================<br>
<br>
Here's my proposed change:<br>
<br>
=================<br>
The default platform tag is distutils.util.get_platform() with all<br>
hyphens - and periods . replaced with underscore _ . If<br>
/etc/os-release [N] exists on the system, then the values in the 'ID'<br>
and 'VERSION_ID' fields are read, all hyphens - and periods . replaced<br>
with underscore _ , and the results appended to the default tag after<br>
a separating underscore."<br>
<br>
Examples:<br>
<br>
* win32<br>
* macosx_10_6_intel<br>
* linux_x86_64_fedora_20<br>
* linux_x86_64_rhel_7_0<br>
* linux_x86_64_debian_7_0<br>
* linux_x86_64_ubuntu_14_04<br>
=================<br>
<br>
The [N] reference would then be a reference to<br>
<a href="http://www.freedesktop.org/software/systemd/man/os-release.html" target="_blank">http://www.freedesktop.org/software/systemd/man/os-release.html</a> for<br>
the definition of the format of os-release. (Note that while the<br>
format originated with systemd, plenty of distros have also started<br>
providing it regardless of which init system they use)<br>
<br>
Now, this slightly overspecifies on the *consumer* side. A binary<br>
wheel that works on "rhel_7_0" for example, should almost certainly<br>
work on "rhel_7_1". However, that can be addressed on the tooling side<br>
(e.g. permitting the specification of "additional compatible<br>
platforms" when invoking pip), rather than needing to be in the<br>
specification.<br>
<br>
This also won't help with older Linux distros that don't offer<br>
/etc/os-release, but I'm OK with that - those can just continue to<br>
show up as "linux_x86_64", and PyPI can continue to disallow those<br>
uploads.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</font></span></blockquote></div><br></div>