On 23 May 2017 at 00:40, Nick Coghlan <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
