[Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Antoine Pitrou]

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."
> 
> 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

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
> specification.

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
build...

While this would be a good technical solution, I think it's socially
disastrous.

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...

Regards

Antoine.