On 23 May 2017 at 00:40, Nick Coghlan 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 | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
