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

[Nick Coghlan]

On 3 June 2017 at 19:45, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> On Sat, Jun 3, 2017, at 03:14 AM, Nathaniel Smith wrote:
>> If the pip devs don't trust build systems in general, but (as
>> suggested by copy_files discussion) are ok with trusting them if they
>> promise to be super trustworthy, alternate proposal:
>> - add a 'in_place_build_safe = True' hook, which indicates that the
>> build system has been carefully written so that this will generate the
>> same result as building an sdist and then building that; pip checks
>> for this to decide whether to build in place or to build an sdist
>> first.
>
> I would use this for flit if it becomes part of the spec. I can see the
> rationale for not trusting build systems from the frontend's point of
> view, but it does feel like all potential build systems are being
> subjected to the same constraints we need for distutils/setuptools.

Think of it in terms of fire doors in a building: those exist not
because we expect all buildings to always be on fire, but because if
there *is* a fire, we want the building to be set up to limit the
ability of smoke and the fire itself to spread.

Breaking up a build pipeline is a similar notion: every stage of the
process is a potential location for bugs, but if you clearly delineate
the steps, you get better natural debugging support simply based on
the ability to identify which step in the pipeline is failing.

If there's only one "build it" hook (e.g. "python setup.py install"),
then folks debugging an installation failure are completely dependent
on the build backend for their ability to diagnose what's going on.

By contrast, if there's a certain process breakdown that backend
developers are obliged to support, then it raises the minimum required
level of debuggability, since it allows a frontend to execute the
build step-by-step and go:

1. Did the sdist generation or build tree extraction work? Yes, good.
2. Did the wheel metadata generation work? Yes, good.
3. Did the actual wheel build work? Yes, good.

If any one of those steps fails, the frontend (and hence the
frontend's users) naturally have more information than if the only
command available was "Build a wheel directly from this VCS checkout".
That kind of thing is less important for publishers and application
integrators (the majority of whom are dealing with dozens or maybe
hundreds of projects at most) than it is for platform integrators (who
are more likely to be dealing with thousands or tens of thousands of
different projects, and hence benefit more from systematic
improvements in fault isolation support).

Cheers,
Nick.

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