[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Nick Coghlan]

On 30 May 2017 at 21:37, Donald Stufft <donald at 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia