[Snip an excellent summary] On 17 July 2017 at 23:02, Nathaniel Smith <n...@pobox.com> wrote:
> - But, if we do support both in-place and out-of-place, then he > strongly feels that there should *not* be any semantic difference > between them "because it just adds another "path" and possible > inconsistency", plus if a build backend is able to do something smart > it should just do it all the time. So I think this is a point of > disagreement between Donald and Nick. Right, but I think it's one we can live with, since it's a difference in expectational norms, rather than a difference in the pragmatic details of the API implementation. Specifically, the whole in-place/out-of-tree distinction evolved in build systems for precompiled languages *because* there are inherent problems with the in-place approach as soon as you have configurable builds (debug vs release, different CPU architectures, different platform ABIs, etc). It's also why the terminology has been evolving and we see some build systems starting to call these "variant" directories, rather than "build" directories. That said, I *have* been persuaded that we shouldn't describe the "build_directory=None" case as requesting an in-place wheel build. Rather, it's more a matter of requesting a "backend-defined default wheel build", as opposed to an "explicitly out-of-tree wheel build". Whether the default build is in-place or out-of-tree will be up to the specific backend. > - Out-of-place is more complicated to implement than in-place, and > it's going to be difficult to explain to build system authors why > we're forcing them to do this extra work for some obscure cases they > might not care about and that we haven't articulated well. Given the change to have an explicit error signal for cases where build_sdist fails for anticipated reasons, I think it would be reasonable to extend that same mechanism to requests for explicitly out-of-tree builds with a frontend specified build directory. That way, backends would have four clear options: 1. (the PEP example case) out-of-tree build = build sdist -> unpack sdist -> build wheel 2. (the flit case) In-place vs out-of-tree is irrelevant, so just ignore the setting 3. (the enscons case) pass the setting down to the underlying build system 4. (the "not supported" case) raise NotImplementedError with a suitable message This approach would also leave frontends like pip with the freedom to implement a 3-tier fallback strategy if they choose to do so (first try building via sdist, then try an explicitly out-of-tree wheel build, and then finally fall back to a fully backend-managed wheel build). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
