On 30 May 2017 at 21:37, Donald Stufft email@example.com 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:
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.
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia