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 <dho...@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 <don...@stufft.io> wrote: > >> On Jun 12, 2017, at 4:01 PM, Thomas Kluyver <tho...@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@python.org >> https://mail.python.org/mailman/listinfo/distutils-sig >> >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
