On 1 December 2014 at 11:41, Marcus Smith <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
