On May 31, 2017, at 4:17 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 30 May 2017 at 21:37, Donald Stufft <donald@stufft.io> wrote:
I don’t think there is any value in decoupling the generation of what goes
into an sdist from the tool that builds them. If we did that, I suspect that
100% of the time the exact same tool is going to be used to handle both
anyways (or people just won’t bother to put in the extra effort to produce
sdists). I think trying to split them up serves only to make the entire
toolchain harder and more complicated for people who aren’t stepped in
packaging lore to figure out what goes where and what does what. The fact
that we have different mechanisms just to control what goes into a sdist
(MANIFEST.in) vs what gets installed (package_data) already confuses people,
further splitting these two steps apart is only going to make that worse.

Keeping the two together also completely sidesteps the problems around “well
what if only the sdist tool is defined but the build tool isn’t?” Or “what
if only the build tool is defined but the sdist tool isn’t?”.

I don't have a strong opinion either way, so I'd also be fine if the
second PEP defined a new optional method for build backends to
implement rather than a new project.toml setting.

So I'd say go ahead and write a new PEP that depends on PEP 517, and
defines the source tree export API you'd like build backends to
provide.

PEP 517 is already fairly complex just in covering the build step, and
trying to also explain the considerations involved in handling the
sdist source export step would likely make it unreadable.

The only constraints I'd place on that proposal up front are:

- it needs to be consistent with the accepted PEP 517 interface
- if the build backend doesn't provide the source tree export method,
then the new PEP should require frontends to fall back to the current
"copy everything" behaviour

Beyond that, since you know what you're looking for, and neither
Thomas nor I fully understand that yet, it makes far more sense you to
write it, and for us to review it as a separate PEP, rather than
trying to incorporate both the additional proposal and its rationale
into PEP 517.

Then one PR to pip can implement support for both PEPs, and everyone
will be happy.


I don’t think an *optional* interface is the correct way to implement this. I’m not entirely sure why folks seem to be ignoring the fact that this is not just for pip, but well, this isn’t just for pip. There are a wide range of popular ecosystem projects depending on the ability to produce a sdist from a given VCS tree, and the current proposal leaves those projects out in the cold.

I also think that the current interface needs some tweaks, some to make it clearer what is being operated on, and some to reduce installation time (basically to avoid a round trip through zip needlessly).

Given that, instead of a separate PEP I’ve just implemented the changes I want to see as a PR which is quite short, it’s a +55 -22 diff and can be viewed at https://github.com/python/peps/pull/275 .



Donald Stufft