[Distutils] Last call for PEP 516 champions

[Nick Coghlan]

On 23 May 2017 at 00:40, Nick Coghlan <ncoghlan at 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 at gmail.com   |   Brisbane, Australia