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

[Daniel Holth]

Once I thought it might be useful to define 'wheel internal manifest'
(whim) format which would just be a list or mapping that looks like
[('category', source path or filelike, destination path), ... ], since that
is basically what wheel is doing, putting paths in categories. Then you get
the data model without worrying about the file format.

On Mon, Jun 12, 2017 at 4:36 PM Daniel Holth <dholth at gmail.com> wrote:

> It's certainly easier to build a zipfile correctly than to build a
> directory tree. Might even be faster if your filesystem is slow. Surely if
> there are multiple *.dist-info it is an error?
>
> On Mon, Jun 12, 2017 at 4:15 PM Donald Stufft <donald at stufft.io> wrote:
>
>> On Jun 12, 2017, at 4:01 PM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>>
>> On Sat, Jun 10, 2017, at 06:14 PM, Nick Coghlan wrote:
>>
>> Thomas - I agree with Donald's reasoning here, so would you mind
>> updating the PEP accordingly?
>>
>>
>> I've done so here:
>> https://github.com/python/peps/pull/290
>>
>> There are still a couple of questions on which I wasn't quite sure what
>> the consensus is:
>>
>> -    Do we want to rename the build_wheel hook now that it makes an
>> unpacked wheel, e.g. export_wheel_contents to match
>> export_sdist_contents?
>>
>>
>>
>> I’m neutral on this, this is just a total bike shed I think so I’m happy
>> to go with whatever you prefer.
>>
>>
>> -    I have assumed that the wheel hook puts its contents in the
>> directory it's passed, rather than creating a subfolder. This is in
>> keeping with the structure of wheels, which do not have a single
>> top-level directory (unlike sdists), but it wouldn't fit with a future
>> hypothetical extension to build multiple wheels at once; we would need a
>> separate hook for that.
>>
>>
>> I don’t think having a separate hook is a bad thing here since we don’t
>> really know specifically what that would look like. However I also don’t
>> think doing something like what we’ve done with prepare_wheel_metadata is
>> out of the question either?
>>
>> One thing I notice is that prepare_wheel_metadata still doesn’t provide a
>> way for the backend to communicate to the frontend what .dist-info folder
>> it should be looking for but it’s currently possible for (mistakeningly or
>> not) to end up with one or more .dist-info files in that directory, so you
>> can’t just glob looking for any dist-info.
>>
>> Perhaps the answer for both of these hooks is to just put the contents
>> into the passed in directory (so remove the {name}-{version}.dist-info
>> directory from prepare_wheel_metadata, and leave the
>> build_wheel/export_wheel_contents, just putting things in the root of the
>> directory and only build this API to handle a single wheel at a time.
>> If/when we add support for multiple wheels at a time, we can then add a new
>> hook to handle that which we can make sure actually supports everything we
>> need at that point, rather than trying to guess what that might look like
>> today?
>>
>>
>> —
>>
>> Donald Stufft
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170612/644b6353/attachment-0001.html>