[Distutils] Working toward Linux wheel support

[Robert Collins]

On 14 August 2015 at 13:38, Wes Turner <wes.turner at gmail.com> wrote:
>
> On Aug 13, 2015 8:31 PM, "Robert Collins" <robertc at robertcollins.net> wrote:
>>
>> On 14 August 2015 at 13:25, Nathaniel Smith <njs at pobox.com> wrote:
>> > On Thu, Aug 13, 2015 at 7:07 AM, Nate Coraor <nate at bx.psu.edu> wrote:
>> >> On Wed, Aug 12, 2015 at 9:05 PM, Nathaniel Smith <njs at 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/book1.html
>
> http://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html


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 at hp.com>
Distinguished Technologist
HP Converged Cloud