On 23 May 2017 at 00:40, Nick Coghlan <ncoghlan@gmail.com> wrote:

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 :)

Since I'm about to accept PEP 517, I'm bringing this rejection forward a couple of days, and officially declaring PEP 516 rejected in favour of PEP 517, with the subprocess CLI being considered a private implementation detail of front-end tools. Thanks Robert and Nathaniel for your work on PEP 516 and your participation in the related discussions :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia