[Distutils] draft PEP: manylinux1

[Nate Coraor]

On Thu, Jan 21, 2016 at 6:31 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Jan 21, 2016 at 2:22 PM, Nate Coraor <nate at bx.psu.edu> wrote:
> > Could this instead use the more powerful json-based syntax proposed by
> Nick
> > here:
> >
> >
> https://mail.python.org/pipermail/distutils-sig/2015-July/026617.html
> >
> > I have already implemented support for this in pip and wheel.
>
> Totally happy to change the compatibility.cfg stuff -- the version in
> the PEP was written in about 5 minutes in hopes of sparking discussion
> :-).
>
> Some other questions:
> 1) is this going to work for multi-arch (binaries for multiple cpu
> architectures sharing a single /etc)? Multiple interpreters? I guess
> the advantage of Nick's design is that it's scoped by the value of
> distutils.util.get_platform(), so multi-arch installs could have
> different values -- a distro could declare that their x86-64 python
> builds are manylinux1 compatible but their i386 python builds aren't.
> Maybe it would be even better if the files were
> /etc/python/binary-compatibility/linux_x86_64.cfg etc., so that the
> different .cfg files could be shipped in each architecture's package
> without colliding. OTOH I don't know if any of this is very useful in
> practice.
>

I don't think the proposed syntax would have any trouble with multiarch
other than that it's contained in one file and so would need to live in a
single package, or be dynamically generated based on which arches you
installed. If that was a problem we could support a
/etc/python/binary-compatibility.d type of thing.


> 2) in theory one could imaging overriding this on a per-venv,
> per-user, or per-system level; which of these are useful to support?
> (Per-system seems like the most obvious, since an important use case
> will be distros setting this flag on behalf of their users.)
>

Per-venv overriding was part of the original proposal and my
implementation, per-user could be useful too.


> There is one feature that I do think is important in the PEP 513
> draft, and that Nick's suggestion from July doesn't have: in the PEP
> 513 design, the manylinux1 flag can be true, false, or unspecified,
> and this is independent of other compatibility settings; in Nick's
> proposal there's an exhaustive list of all compatible tags, and
> everything not on that list is assumed to be incompatible. Where this
> matters is when we want to release manylinux2. At this point we'll
> want pip to use some autodetection logic on old distros that were
> released before manylinux2, while respecting the compatibility flag on
> newer distros that do know about manylinux2. This requires a tri-state
> setting with "not specified" as a valid value.
>

One solution would be `compatible` and `incompatible` keys rather than
`install`?

--nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160129/408eb04b/attachment-0001.html>