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

Nick Coghlan ncoghlan at gmail.com
Fri Nov 28 16:27:44 CET 2014

On 28 November 2014 at 18:19, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 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?

Only if folks publish Linux binaries themselves, and that's still a
bad idea (for the same reason publishing distro binaries is already a
rare thing for people to do).

>> 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)?

They tend to publish /etc/os-release as well these days, and there's
actually a mechanism built into that for clients to flag other distros
to try.

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

I'd still advise against folks posting Linux wheels on PyPI, just as
they tend not to post RPM or deb files. This is so we can provide
wheels at the distro level (or build them internally) without creating
vast amounts of confusion.

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

Only if you're expecting folks to regularly publish their own wheels
to PyPI. This isn't really about that - it's about having a way to
tackle it at the distro level, without introducing significant
potential for confusion on end user systems
describes the Fedora side of our current work in this area)

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

The difference isn't really that surprising - both Microsoft and Apple
have relied heavily on intellectual monopoly laws to retain control of
their ecosystems. You can do a lot to constrain the choices of others
when you have the full weight of the US government and copyright
industry behind you.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list