On Sun, Jun 25, 2017 at 12:26 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 25 June 2017 at 16:58, Nathaniel Smith <njs@pobox.com> wrote:
The current spec's solution:
- Let's define an exhaustive list of all the reasons you might want to make an sdist: 1) you're a hypothetical future version of pip that has decided to implement some specific build-from-unpacked-source-tree semantics 2) the user has specifically requested an sdist, so if one can't be made then the only thing to do is to fail and pass on some unstructured error log 3) that's it, we've made a list of all possible front-end semantics. - Then define a hook that does (1) and a hook that does (2).
pip doesn't care about making sdists, it only cares about doing out of tree wheel builds. It's other tools (e.g. tox) that specifically care about making sdists.
So we only have two front-end scanarios that we need to handle:
1. preparing for an out-of-tree call to build_wheel 2. actually building an sdist (e.g. for testing or publication)
Right, the core point of disagreement is: - I'm not convinced that this list is exhaustive. - I'm not convinced that we understand the out-of-tree build case, given that the sdist approach has never been implemented or deployed. - Even based on our current imperfect understanding of the out-of-tree build case, I'm not convinced that prepare_build_wheel_files solution is actually the best solution. (For all the reasons I've said before: the stated motivation for doing out-of-tree builds is that we don't trust the build system, but prepare_build_wheel_files forces us to trust the build system; flit *could* support sdists, the question is whether it's worth the effort, and I don't believe we really understand the trade-offs well enough to know the answer to that; in the flit case copytree() would work just as well as prepare_build_wheel_files anyway so there's no demonstrated need for this complexity.) Maybe you're right and there are exactly 2 front-end use cases and it will turn out that the current PEP addresses them perfectly. I don't have a crystal ball; I'm making an argument from ignorance. But I feel like allowing NotImplemented returns + ext_{toolname}_* hooks seems like it covers all the known cases about as well as the current design, while being substantially simpler and more future-proof. -n -- Nathaniel J. Smith -- https://vorpus.org