[Distutils] Last call for PEP 516 champions

[Nick Coghlan]

Hi folks,

The restarted discussion on PEP 517 meant I realised that we hadn't
officially decided between its Python API based approach and PEP 516's
approach of using the backend CLI as the standardised interface (akin
to the current setup.py approach).

My current intention is to reject PEP 516's CLI standardisation
approach on the following grounds:

- PEP 517 makes a convincing case for the benefits of the Python API
based approach within the Python ecosystem
- the difficulties encountered in evolving the setup.py CLI over time
lend significant weight to the notion that a Python level API will be
easier to update without breaking backwards compatibility
- PEP 517 still advises front-ends to isolate back-end invocation
behind a subprocess boundary due to all of the other practical
benefits that brings, it just makes the specifics of that invocation
an implementation detail of the front-end tool
- third party tools that want an implementation language independent
CLI abstraction over the Python ecosystem (including builds) can just
use pip itself (or another standards-compliant frontend)

This isn't particularly urgent, but I also don't see a lot of reason
for an extended discussion, so if I don't hear a convincing
counterargument in the meantime, I'll mark the PEP as rejected at the
beginning of June :)

Cheers,
Nick.

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