On Fri, Aug 21, 2015 at 2:51 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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 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. 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. 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). --nate > > > 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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
