[Distutils] abstract build system approaches redux

[Nick Coghlan]

On 3 March 2016 at 10:43, Robert Collins <robertc at robertcollins.net> wrote:
> Python vs CLI - I don't care enough to argue. I think a CLI is better
> in this space, as running commands is the lingua franca of CLI's;
> previously Donald has advocated for that as well, but his proposal is
> now a Python API. *shrug*. I want the BDFL-Delegate to choose.

I'm happy to let the discussion run for the other open questions you
mention, but I'm now prepared to pronounce on this aspect based on one
specific factor: I don't want to mandate that all future build systems
for Python projects (whether front ends or back ends) must be written
in Python.

If somebody comes up with an all-singing, all-dancing Python build
system that happens to be written in Go, or Rust, or Haskell, or that
they made by adapting an existing build system for another language
ecosystem to have native support for also building Python packages,
I'd like for the Python packaging ecosystem to be able to handle that
without significant fuss.

Attaining that level of cross-language interoperability then
necessarily means defining the formal build system abstraction
interface at the CLI boundary, rather than as a Python API.

Defining a helper library/framework to make it *easier* to write new
build systems in Python would still make sense, but that can be done
in the usual way that any other library gains widespread acceptance:
by being easier to use than a "DIY" approach when it comes to directly
implementing the underlying interoperability specification.

Regards,
Nick.

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