On Fri, Jul 7, 2017 at 4:05 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 7 July 2017 at 11:30, Nathaniel Smith <n...@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.
...? The text I was replying to was about adding a new argument to build_wheel that backends would have to check for and do special things based on. I mean, I really do see the attraction of requiring all build systems to support "build directories", that potentially enables some neat things like caching the directories across builds, but it's clearly a novel technical proposal, and one that's actually attempting to go beyond the rest of the world's build system state-of-the-art at a time when we're still trying to catch up with the capabilities of like, automake circa 2000. > 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...) I am resigned to pip doing whatever it wants :-). At this point I just want to get something clean and functional landed that we can build on with a minimum of warts that we end up regretting later. If there's no way to land a workable build_wheel without this extra stuff, then OK; that's why I asked. But if it can be split into a future PEP then I think we should. > 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). It mandates that all backends implement both in-place and out-of-place builds, including those backends which can do in-place builds correctly (e.g. projects that produce compiled artifacts but which accurately tell when they need to rebuild). Which is a little surprising, because what we actually care about is correct builds, and out-of-place builds are just one possible strategy for that. It's certainly one approach, but I don't feel confident that we can quickly and accurately determine that it's *the* best approach that we want to commit to forever. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
