On Aug 13, 2015 8:38 PM, "Wes Turner" <wes.tur...@gmail.com> wrote: > > > On Aug 13, 2015 8:31 PM, "Robert Collins" <robe...@robertcollins.net> wrote: > > > > On 14 August 2015 at 13:25, Nathaniel Smith <n...@pobox.com> wrote: > > > On Thu, Aug 13, 2015 at 7:07 AM, Nate Coraor <n...@bx.psu.edu> wrote: > > >> On Wed, Aug 12, 2015 at 9:05 PM, Nathaniel Smith <n...@pobox.com> wrote: > > >>> > > >>> From my reading of what the Enthought and Continuum folks were saying > > >>> about how they are successfully distributing binaries across different > > >>> distributions, it sounds like the additional piece that would take this from > > >>> a interesting experiment to basically-immediately-usable would be to teach > > >>> pip that if no binary-compatibility.cfg is provided, then it should assume > > >>> by default that the compatible systems whose wheels should be installed are: > > >>> (1) the current system's exact tag, > > >> > > >> This should already be the case - the default tag will no longer be > > >> -linux_x86_64, it'd be linux_x86_64_distro_version. > > >> > > >>> > > >>> (2) the special hard-coded tag "centos5". (That's what everyone actually > > >>> uses in practice, right?) > > >> > > >> The idea here is that we should attempt to install centos5 wheels if more > > >> specific wheels for the platform aren't available? > > > > > > Yes. > > > > > > Or more generally, we should pick some common baseline build > > > environment such that we're pretty sure wheels built there can run on > > > 99% of end-user systems and give this environment a name. (Doesn't > > > have to be "centos5", though IIUC CentOS 5 is what people are using > > > for this baseline build environment right now.) That way when distros > > > catch up and start providing binary-compatibility.cfg files, we can > > > give tell them that this is an environment that they should try to > > > support because it's what everyone is using, and to kick start that > > > process we should assume it as a default until the distros do catch > > > up. This has two benefits: it means that these wheels would actually > > > become useful in some reasonable amount of time, and as a bonus, it > > > would provide a clear incentive for those rare distros that *aren't* > > > compatible to document that by starting to provide a > > > binary-compatibility.cfg. > > > > Sounds like a reinvention of LSB, which is still a thing I think, but > > really didn't take the vendor world by storm. > > LSB == "Linux System Base" > > It really shouldn't be too difficult to add lsb_release to the major distros and/or sys.plat*
Salt grains implement this functionality w/ many OS: https://github.com/saltstack/salt/blob/110cae3cdc1799bad37f81f2/salt/grains/core.py#L1229 ("osname", "osrelease") [Apache 2.0] > > http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/book1.html > > http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html > > > > > -Rob > > > > -- > > Robert Collins <rbtcoll...@hp.com> > > Distinguished Technologist > > HP Converged Cloud > > _______________________________________________ > > 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
