[Distutils] PEP 517: Open questions around artifact export directories

[Nathaniel Smith]

On Mon, Jun 12, 2017 at 4:41 PM, Donald Stufft <donald at stufft.io> wrote:

>
> On Jun 12, 2017, at 7:18 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
> On Mon, Jun 12, 2017 at 3:49 PM, Donald Stufft <donald at stufft.io> wrote:
>
>>
>> On Jun 12, 2017, at 6:36 PM, Nathaniel Smith <njs at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170612/49eebaa9/attachment.html>