<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 4:36 PM Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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?</div></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 12, 2017 at 4:15 PM Donald Stufft <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 12, 2017, at 4:01 PM, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</a>> wrote:</div><br class="m_4541740256172031069m_-914784803503165007m_923009792936715130Apple-interchange-newline"><div><div>On Sat, Jun 10, 2017, at 06:14 PM, Nick Coghlan wrote:<br><blockquote type="cite">Thomas - I agree with Donald's reasoning here, so would you mind<br>updating the PEP accordingly?<br></blockquote><br>I've done so here:<br><a href="https://github.com/python/peps/pull/290" target="_blank">https://github.com/python/peps/pull/290</a><br><br>There are still a couple of questions on which I wasn't quite sure what<br>the consensus is:<br><br>-    Do we want to rename the build_wheel hook now that it makes an<br>unpacked wheel, e.g. export_wheel_contents to match<br>export_sdist_contents?</div></div></blockquote><div><br></div><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I’m neutral on this, this is just a total bike shed I think so I’m happy to go with whatever you prefer.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div><div>-    I have assumed that the wheel hook puts its contents in the<br>directory it's passed, rather than creating a subfolder. This is in<br>keeping with the structure of wheels, which do not have a single<br>top-level directory (unlike sdists), but it wouldn't fit with a future<br>hypothetical extension to build multiple wheels at once; we would need a<br>separate hook for that.<br></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><br><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>—</div></div></div><div style="word-wrap:break-word"><div><div style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>Donald Stufft<br></div></div></div>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div></div></blockquote></div>