On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith <n...@pobox.com> wrote:
> How does this affect spec-writing? Well, we want to allow for non-pip
> installers, so the part that pip does has to be specified. But pip's
> part is really straightforward.
[...]
> So the proposal here is to refactor the spec to match how this
> actually works: the official definition of a manylinux_${glibc
> version}_${arch} wheel would be "I promise this wheel will work on any
> Linux system with glibc >=${glibc version} and an ${arch} processor".
> We'll still need to make changes as old distros go out of support, new
> architectures get supported, etc., but the difference is, those
> changes won't require complex cross-ecosystem coordination with new
> formal specs for each one; instead they'll be routine engineering
> problems for the docker image+auditwheel maintainers to solve.So if I follow, what you're saying is that the *spec* (i.e., the PEP) will simply say what installers like pip, and indexes like warehouse need to do[1] (which is for pip, generate the right list of supported tags, and for warehouse, add the relevant tags to the "allowed uploads" list). And everything else (all the stuff about libraries you're allowed to link dynamically to) becomes just internal design documentation for the auditwheel project (and amy other manylinux building support projects that exist)? That sounds reasonable. Paul [1] Is there not also an element of what the wheel project needs to do? It has to generate wheels with the right tags in the first place. Actually, PEP 425 also needs an update, at a minimum to refer to the manylinux spec(s), which modify the definition of a "platform tag" from PEP 425... -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/Y2JHGHOWPJ7SPBTPGSMMDIDHIVXWTO2F/
