Also, please note that the proposal doesn't *prohibit* in-place
builds, quite the opposite, it allows backends to decide when asked
how to implement both in-place and out of place builds (where the
current tree allows backends to decide how to do in place builds and
how to copy trees, and leaves the frontend to decide how to implement
out of place builds, typically via something like a tree copy and
subsequent in-place build).

On 7 July 2017 at 12:05, Paul Moore <p.f.moore@gmail.com> wrote:
> On 7 July 2017 at 11:30, Nathaniel Smith <njs@pobox.com> wrote:
>> Is it absolutely necessary to get this into the first PEP?
>
> As far as I'm concerned, it's no more than a restating (and
> simplification?) of all the discussions around building out of tree
> via creating an sdist and unpacking it, or having the various prepare
> files hooks. It's always been there and always been a requirement.
>
>> This proposal creates substantial complications for build systems that default to doing in-place builds
>
> Well, we're focused on build systems that will get a PEP 517
> interface, so far the only concrete examples we have are flit (which
> has no problem with this), enscons (which has no problem with it) and
> probably setuptools, in some form (which needs out-of-tree builds
> based on our experience with it in pip, although I concede that you
> would argue that point).
>
> Also, out of tree builds are something that pip is planning on
> implementing, and for us it's therefore necessary to have hooks that
> let us do that. The current version of the PEP provides those hooks,
> and we're planning on using them to do out of tree builds. This new
> suggestion is basically backend authors saying "you don't need to do
> the out of place builds, we're willing to take responsibility for
> that". If you're saying that you're not happy with that, then all that
> will end up happening is we revert to the previous approach, and pip
> implements out of tree builds based on that (and I guess you have the
> same argument all over again on the PR for the pip change...)
>
> Paul
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig