On 21 August 2015 at 05:58, Robert Collins <robe...@robertcollins.net> wrote: > On 21 August 2015 at 07:25, Donald Stufft <don...@stufft.io> wrote: >> >> On August 20, 2015 at 3:23:09 PM, Daniel Holth (dho...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig