+1 to the idea in general.
Would this be an *edit* to PEP425/427/Wheel-1.0 OR new peps, and a new
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
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 <ncog...@gmail.com> 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 | ncog...@gmail.com | Brisbane, Australia> _______________________________________________> Distutils-SIG maillist - Dist...@python.org> https://mail.python.org/mailman/listinfo/distutils-sig>
Distutils-SIG maillist - Dist...@python.org