[Distutils] Provisionally accepting PEP 517's declarative build system interface

Paul Moore p.f.moore at gmail.com
Sat Jun 3 05:29:42 EDT 2017

On 3 June 2017 at 08:47, Donald Stufft <donald at stufft.io> wrote:
> That also means that we can adjust our answer to it in the future. If such a
> tool gets built and a lot of people end up using it and asking for it in
> pip, we can revisit that decision in a future version of pip. Part of the
> stand off here is the pip developers view it as a regression if we stop
> building in isolation and you view it as a regression if incremental/inplace
> builds are not supported. Both can be true! It’s the opinion of the pip
> developers who have spoken so far that for us, the risk of our regressions
> is high enough we don’t currently feel comfortable changing that behavior.

In summary (for my own benefit as much as anything):


1. pip provides out-of-tree builds for directories
2. the backend (setup.py) provides in-place builds

Under PEP 517:

1. pip provides out-of-tree builds for directories (optimised via the
build_sdist and or copy_files hooks)
2. the backend (see below) provides in-place builds

The PEP 517 backend for setup.py builds may be something new, or it
may be setup.py plus some "support legacy source trees" code in pip.
It largely depends on who wants to write and maintain PEP 517 adapter
code for setup.py. That's not clear to me yet. OTOH, numpy retaining
setup.py and relying on legacy support for that format will work for
some time yet, so there's no rush to move to a new backend.


1. the numpy developers can make a case for a new pip feature, to do
in-place builds, PEP 517 has the build_wheel hook that allows this to
be implemented

Did I miss anything? Based on this, in-place builds don't seem like
they are a big deal (as long as we can agree that "pip doesn't provide
in-place builds" isn't a huge issue that's suddenly appeared).


More information about the Distutils-SIG mailing list