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

On Fri, 28 Nov 2014 16:03:59 +1000
Nick Coghlan <ncog...@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.


_______________________________________________
Distutils-SIG maillist  -  Dist...@python.org
https://mail.python.org/mailman/listinfo/distutils-sig