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

[Nick Coghlan]

On 1 December 2014 at 11:41, Marcus Smith <qwcode at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia