On Thu, Jan 21, 2016 at 6:31 PM, Nathaniel Smith <[email protected]> wrote:
> On Thu, Jan 21, 2016 at 2:22 PM, Nate Coraor <[email protected]> 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
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
