[Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files
solipsis at pitrou.net
Fri Nov 28 09:19:51 CET 2014
On Fri, 28 Nov 2014 16:03:59 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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."
> * 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
Is this not going to be a slippery slope?
> 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
How about those lesser known distributions (e.g. Linux Mint or Mageia)?
How many binary packages will package authors have to provide to cover
people's needs? Windows + OS X + Linux multiplied by 32 / 64 multiplied
by three or four Python versions is already a lot of binaries to
While this would be a good technical solution, I think it's socially
Of course, you may point out that it has its roots in the failure of the
GNU/Linux ecosystem to provide real binary compatibility. It's stunning
that under Windows you can build a Windows XP-compatible shared library
with a recent MSVC just by turning a switch in the options...
More information about the Distutils-SIG