[Distutils] Last call for PEP 516 champions

Nick Coghlan ncoghlan at gmail.com
Sun May 28 21:34:28 EDT 2017

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


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

More information about the Distutils-SIG mailing list