| Store | Cart

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

From: Nick Coghlan <ncog...@gmail.com>
Sat, 29 Nov 2014 01:27:44 +1000
On 28 November 2014 at 18:19, Antoine Pitrou <soli...@pitrou.net> wrote:
> 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?

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
(https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepositories
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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncog...@gmail.com   |   Brisbane, Australia
_______________________________________________
Distutils-SIG maillist  -  Dist...@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Recent Messages in this Thread
Nick Coghlan Nov 28, 2014 06:03 am
Antoine Pitrou Nov 28, 2014 08:19 am
Nick Coghlan Nov 28, 2014 03:27 pm
Antoine Pitrou Nov 28, 2014 03:51 pm
Nick Coghlan Nov 29, 2014 03:47 pm
Antoine Pitrou Nov 29, 2014 04:10 pm
Nick Coghlan Nov 29, 2014 05:02 pm
Donald Stufft Nov 29, 2014 05:40 pm
Antoine Pitrou Nov 29, 2014 05:41 pm
Tres Seaver Nov 29, 2014 05:39 pm
Marius Gedminas Nov 28, 2014 08:40 am
Matthias Klose Nov 28, 2014 03:31 pm
Nick Coghlan Nov 28, 2014 03:38 pm
Marcus Smith Dec 01, 2014 01:41 am
Olivier Grisel Dec 02, 2014 10:57 am
Nick Coghlan Dec 02, 2014 11:56 am
Messages in this thread