On 3 March 2016 at 10:43, Robert Collins <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
