On 3 June 2017 at 08:47, Donald Stufft firstname.lastname@example.org 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):
Under PEP 517:
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.
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).