On Mon, Jun 12, 2017 at 4:41 PM, Donald Stufft <don...@stufft.io> wrote:
> > On Jun 12, 2017, at 7:18 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Mon, Jun 12, 2017 at 3:49 PM, Donald Stufft <don...@stufft.io> wrote: > >> >> On Jun 12, 2017, at 6:36 PM, Nathaniel Smith <n...@pobox.com> wrote >> >> Another point is that tools that you might have in your build pipeline >> -- like auditwheel -- currently use wheel files as their interchange >> format, so you might end up having to zip, run auditwheel, unzip for >> pip, and the pip zips again to cache the wheel… >> >> >> How is that different from today? In the hypothetical build_wheel >> producing a zip file… you produce a zip file, run auditwheel which unzips >> it, which presumably has to zip it back up again for pip, and then pip >> unzips it again on every single install. >> >> If auditwheel doesn’t start to accept unzipped wheels, then nothing >> changes, if it does then suddenly we skip some round trips through >> zip/unzip and things get faster for everyone. >> > > I would strongly prefer auditwheel not have to accept unzipped wheel or > generate unzipped wheels, because that just multiples the number of cases > that need to be supported, and as you've pointed out many times, more > potential paths = more chances for bugs. So if you have auditwheel as the > last step in your pipeline, that means that at the end of the build what > you have is a zipped wheel. If pip accepts zipped wheels, then we can just > hand this over and pip drops it in its cache and unzips it into the final > location. If pip requires unpacked wheels, then first the backend has to > unzip it, and then pip has to do something with the unpacked directory > (either copy it file-by-file, or possibly even zip it up again to cache it). > > > Unless audit wheel is calling this backend directly, or is trying to > implement this API to be called by pip, then it never has to do that. This > isn’t really meant to be an end user exposed UX, this is strictly for two > tools to talk to each other. Thus auditwheel is free to continue to work as > it does today and it can completely ignore this spec by just continuing to > expect someone to invoke a command that builds a wheel first. > Yeah, I'm talking about the currently-hypothetical situation where the build backend wants to call auditwheel as part of its build. Auditwheel's current design as a secondary tool you run after the "real" build is expedient, but it would be nice if someday build systems could generate working wheels directly... -n -- Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
