On 14 August 2015 at 13:38, Wes Turner <wes.turner@gmail.com> wrote:
On Aug 13, 2015 8:31 PM, "Robert Collins" <robertc@robertcollins.net> wrote:
On 14 August 2015 at 13:25, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Aug 13, 2015 at 7:07 AM, Nate Coraor <nate@bx.psu.edu> wrote:
On Wed, Aug 12, 2015 at 9:05 PM, Nathaniel Smith <njs@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*
http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/bo...
http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ls...
So its already there; the point I was making was the LSB process and guarantees, not lsb_release, which is a tiny thing. -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud