On Fri, Nov 30, 2018 at 10:29 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith <njs@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)?
Yep.
[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...
We've actually never touched the wheel project in any of the manylinux work. The workflow is: - set up the special build environment - run setuptools/wheel to generate a plain "linux" wheel (this is the not-very-useful tag that for historical reasons just means "it works on my machine", and isn't allowed on pypi) - auditwheel processes the "linux" wheel to check for various possible issues, vendor any necessary libraries, and if that all worked then it rewrites the metadata to convert it to a "manylinux" wheel This feels a bit weird somehow, but it's worked really well so far. Note that in a PEP 517-based world, regular local installs also create an intermediate wheel, and in that case you don't want the special auditwheel handling, you really just want the "it works on my machine" wheel. -n -- Nathaniel J. Smith -- https://vorpus.org