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) The possibility of only defining one hook arises from the fact that providing just the build_sdist hook would be sufficient for both tasks *if* we were willing to impose the constraint that everything a backend depends on to build an sdist will always also be a pre-requisite for building a wheel file. Thomas has indicated that that *isn't* the case for flit - he expects the `build_sdist` hook to need runtime dependencies (either Python level or external) that `build_wheel` doesn't. Thus `prepare_build_wheel_files` to cover the case where the frontend doesn't really want an sdist at all, it just wants to do an out-of-tree wheel build, but the backend doesn't want to ensure that the preconditions for `build_sdist` and `build_wheel` are identical. However, we've chosen to make the second hook optional, so backends that have a very simple `build_sdist` implementation don't have to worry about the optional wheel preparation hook. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia