On 20 July 2017 at 19:46, Nathaniel Smith <n...@pobox.com> wrote: > Hi all, > > So looking over the big threads from the last week, I *think* I have a > reasonable sense of what different people think about the different > trade-offs here... but I'm not sure. And I'm guessing I'm not the only > one feeling uncertain here. > > So in this post I'm not going to argue for anything at all! It's > purely for information gathering, to try and stop, take stock, and > figure out where everyone actually is at this point. > > To make this concrete: I'm *pretty* sure (?) that at this point all > the basic elements in my "simplified" rewrite are things that we now > have consensus are needed in some form, so maybe we can use that as a > kind of "minimal core" reference point: > > https://github.com/njsmith/peps/commits/517-refactor-streamline/pep-0517.txt > > (Again, I'm NOT arguing for this right now, I just figure there's been > enough stuff flying by that it's useful to have a concrete reference > point.)
Thomas was generally updating the PEP in parallel with the discussions, so the API specification at https://www.python.org/dev/peps/pep-0517/ is complete (and includes many of the layout improvements that had been suggested). The main functional difference between it and your last draft is that it includes the "build_directory" parameter to build_wheel. There's also one pending PR from me awaiting his review: https://github.com/python/peps/pull/311 The pending PR doesn't change the API specification at all, it just removes out of date references to `get_wheel_metadata` (either by updating them to use `get_metadata_for_build_wheel`, or else switching them to refer to a different API entirely). The one functional change request not covered in either the current PEP or the pending PR is: - explicitly adding "raise NotImplementedError" to indicate that build_sdist or an explicitly out-of-tree build request failed for anticipated reasons (and to describe those reasons) Which then leads to the following open questions: - can build_sdist preconditions be checked and NotImplementedError raised from get_requires_for_build_sdist? - can build_wheel preconditions be checked and NotImplementedError raised from get_requires_for_build_wheel? (My inclination is to say "No" to both of those, since they would complicate usage of the API without actually making it any more expressive) It also became clear that the following points still need to be clarified in relation to the "build_wheel" hook: - fixing the reference to "unspecified semantics" to be explicit that the only way for a frontend to ensure that a built wheel is consistent with an sdist is to build from that sdist (either one the frontend received from the command line, downloaded or created with build_sdist). Depending on the backend, building a wheel directly from a non-sdist source tree may be inconsistent with building from an sdist, as it may end up including files that the sdist creation process would have filtered out. - documenting the 4 expected implementation strategies for the build_directory parameter (implementing it via build_sdist, delegating it to an external build system, ignoring it as irrelevant, raising an error) - fixing the definition of "build_directory=None" to say that it requests a default backend-managed build, which may be either in-place or out-of-tree, depending on how that particular backend works And I'm still opposed to postponing the ability for frontends to explicitly request out-of-tree builds - we already know how we want them to work, and granting backends the ability to write "raise NotImplementedError('This backend does not support explicit out-of-tree builds')" effectively makes them optional, so we won't gain anything from delaying them, while postponing them would incur a bunch of additional evolutionary costs as we ask backend authors to try to hit a moving target. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
