| Store | Cart

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

From: Nick Coghlan <ncog...@gmail.com>
Tue, 2 Dec 2014 21:56:13 +1000
On 1 December 2014 at 11:41, Marcus Smith <qwc...@gmail.com> wrote:
> +1 to the idea in general.> Would this be an *edit* to PEP425/427/Wheel-1.0  OR new peps, and a new> wheel version?

I'm currently thinking no change to the wheel spec, but potentially a
PEP to define a standard way to override and/or supplement the default
compatibility tags.

> As someone using cent6 daily (with no os-release file), I'm greedy for> another fallback technique, but the simplicity of just using os-release> makes sense.> Could a published "linux_x86_64_fedora_20" wheel ever become broken just due> to normal "yum update" activity on fedora_20?  When? Why?

It's technically possible to get an ABI break mid-cycle on Fedora, as
it doesn't have the same level of restrictions against rebasing
components that RHEL/CentOS do. Actually encountering an ABI break
would still be pretty unlucky though.

However, I realised my original idea doesn't quite work, since
derivative distros may strive to be ABI compatible with their
upstreams. While /etc/os-release sort of supports that concept via
ID_LIKE, it's entirely vague about what that actually means, and the
"ID_LIKE" distro references aren't versioned at all. There's also the
fact that at least RHEL/CentOS aim to remain ABI compatible for the
duration of an entire release series, so including the full version of
/etc/os-release would overspecify things.

That got me back to the idea of being able to customise the platform
tag which various folks have brought up in the past. At that point,
the definition in PEP 425 would become the specification for the
*default* platform tag, and we'd look at adding ways to override it
both when building wheels and when installing them.

The main possibility I thought of there was to come up with a
convention for overriding the platform tag at the *virtual
environment* level. Then bdist_wheel, pip and other projects could
check for the override before falling back to the default definition
from PEP 425. If we designed the mechanisms correctly, it could
potentially also be used to address the "no SOABI details" problem on
Python 2.7.

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