<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 21, 2015 at 2:51 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 August 2015 at 05:58, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> On 21 August 2015 at 07:25, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
>><br>
>> On August 20, 2015 at 3:23:09 PM, Daniel Holth (<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>) wrote:<br>
>>> If you need that for some reason just put the longer information in the<br>
>>> metadata, inside the WHEEL file for example. Surely "does it work on my<br>
>>> system" dominates, as opposed to "I have a wheel with this mnemonic tag,<br>
>>> now let me install debian 5 so I can get it to run".<br>
>>><br>
>>><br>
>><br>
>> It’s less about “now let me install Debian 5” and more like tooling that doesn’t run *on* the platform but which needs to make decisions based on what platform a wheel is built for.<br>
><br>
> Cramming that into the file name is a mistake IMO.<br>
><br>
> Make it declarative data, make it indexable, and index it. We can do<br>
> that locally as much as via the REST API.<br>
><br>
> That btw is why the draft for referencing external dependencies<br>
> specifies file names (because file names give an ABI in the context of<br>
> a platform) - but we do need to identify the platform, and<br>
> platform.distribution should be good enough for that (or perhaps we<br>
> start depending on lsb-release for detection<br>
<br>
</span>LSB has too much stuff in it, so most distros aren't LSB compliant out<br>
of the box - you have to install extra packages.<br>
<br>
/etc/os-release is a better option:<br>
<a href="http://www.freedesktop.org/software/systemd/man/os-release.html" rel="noreferrer" target="_blank">http://www.freedesktop.org/software/systemd/man/os-release.html</a></blockquote><div><br></div>As per this discussion, and because I've discovered that the entire platform module is deprecated in 3.5 (and other amusements, like a Ubuntu-modified version of platform that ships on Ubuntu - platform as shipped with CPython detects Ubuntu as debian), I'm switching to os-release, but even that is unreliable - the file does not exist in CentOS/RHEL 6, for example. On Debian testing/sid installs, VERSION and VERSION_ID are unset (which is not wrong - there is no release of testing, but it does make identifying the platform more complicated since even the codename is not provided other than at the end of PRETTY_NAME). Regardless of whether a hash or a human-identifiable string is used to identify the platform, there still needs to be a way to reliably detect it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Unless someone tells me not to, I'm going to default to using os-release and then fall back to other methods in the event that os-release isn't available, and this will be in some sort of library alongside pep425tags in wheel/pip.</div><div class="gmail_quote"><br></div><div class="gmail_quote">FWIW, os-release's `ID_LIKE` gives us some ability to make assumptions without explicit need for a binary-compatibility.cfg (although not blindly - for example, CentOS sets this to "rhel fedora", but of course RHEL/CentOS and Fedora versions are not congruent).</div><div class="gmail_quote"><br></div><div class="gmail_quote">--nate</div><div class="gmail_quote"> <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
My original concern with using that was that it *over*specifies the<br>
distro (e.g. not only do CentOS and RHEL releases show up as different<br>
platforms, but so do X.Y releases within a series), but the<br>
binary-compatibility.txt idea resolves that issue, since a derived<br>
distro can explicitly identify itself as binary compatible with its<br>
upstream and be able to use the corresponding wheel files.<br>
<span class="im HOEnZb"><br>
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>