On 3 June 2017 at 08:47, Donald Stufft <don...@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): Currently: 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. Future: 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). Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
