On 21 August 2015 at 05:58, Robert Collins <robertc@robertcollins.net> wrote:
On 21 August 2015 at 07:25, Donald Stufft <donald@stufft.io> wrote:
On August 20, 2015 at 3:23:09 PM, Daniel Holth (dholth@gmail.com) wrote:
If you need that for some reason just put the longer information in the metadata, inside the WHEEL file for example. Surely "does it work on my system" dominates, as opposed to "I have a wheel with this mnemonic tag, now let me install debian 5 so I can get it to run".
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.
Cramming that into the file name is a mistake IMO.
Make it declarative data, make it indexable, and index it. We can do that locally as much as via the REST API.
That btw is why the draft for referencing external dependencies specifies file names (because file names give an ABI in the context of a platform) - but we do need to identify the platform, and platform.distribution should be good enough for that (or perhaps we start depending on lsb-release for detection
LSB has too much stuff in it, so most distros aren't LSB compliant out of the box - you have to install extra packages. /etc/os-release is a better option: http://www.freedesktop.org/software/systemd/man/os-release.html My original concern with using that was that it *over*specifies the distro (e.g. not only do CentOS and RHEL releases show up as different platforms, but so do X.Y releases within a series), but the binary-compatibility.txt idea resolves that issue, since a derived distro can explicitly identify itself as binary compatible with its upstream and be able to use the corresponding wheel files. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia