On 3 June 2017 at 02:50, Thomas Kluyver firstname.lastname@example.org wrote:
On Fri, Jun 2, 2017, at 05:26 PM, Nick Coghlan wrote:
Could you provide a little more detail as to what you would do differently in exporting the contents of an sdist that wouldn't apply to export a build tree? (aside from skipping emitting PKG-INFO)
When creating an sdist, I query the VCS to work out what files to put in it. This is brittle - it depends on the directory being a VCS checkout, and the relevant VCS being available to call. And it's relatively slow, because we have to shell out to another process. I've decided those are acceptable trade-offs for the project maintainer making the release.
When exporting a build tree, I would copy only the files that are needed to make the wheel. This is simple, robust and fast.
Oh, I get it - for a build tree, you know which files you really need (since it's specified as part of flit's settings), whereas for the sdist, you also need to get all the other files that the build doesn't need, but the sdist should contain anyway.
And this distinction will become even more important if Nathaniel gets his wish and we some day extend the backend API definition to support generating multiple wheel files from the same sdist.
I can even generate PKG-INFO when exporting a build tree if that helps.
Now that I understand the point you were making, I don't think that's necessary.
But I want to keep the idea of a build tree used as an intermediate to generating a wheel separate from that of an sdist, which is a release artifact.
Right, that makes sense to me now. It also means that even when building from a VCS checkout, you may not need the tools to query that VCS if things like your version number are specified in a static file.
-- Nick Coghlan | email@example.com | Brisbane, Australia