On 3 June 2017 at 19:45, Thomas Kluyver email@example.com 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:
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:
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).
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia