On Jun 16, 2017, at 5:48 PM, Nathaniel Smith <njs@pobox.com> wrote:

On Fri, Jun 16, 2017 at 2:08 AM, Thomas Kluyver <thomas@kluyver.me.uk> wrote:

On Fri, Jun 16, 2017, at 08:41 AM, Nick Coghlan wrote:
I think we should rename get_build_requires to
get_build_wheel_requires, and add a get_build_sdist_requires. And the
rule would be:

get_build_sdist_requires: can assume build-system.requires are available
get_build_wheel_requires: can assume build-system.requires are available

build_sdist: can assume build-system.requires and
get_build_sdist_requires are available
prepare_wheel_metadata, build_wheel: can assume build-system.requires
and get_build_wheel_requires are available

+1 from me

*Sigh*, another hook. It makes sense in context, but I can't shake the
feeling that what was a relatively simple spec is steadily turning into
a complex monster. I still resent that we're trying to standardise an
interface to build sdists at the same time as one to build wheels.

Hmm, here's another plea for simplicity, but from a slightly different
direction that I just thought of: what if we said that any hooks
starting with "ext_pip_..." are reserved for pip's use, and pip can
make up whatever semantics it likes for them. And then as the parts of
pip that actually want to use prepare_wheel_metadata and/or
get_prepared_wheel_input_files come online, we use the ext_pip_*
versions of those hooks to prototype them and work out any issues. And
then once there's an actual implementation and proven value, we write
a new PEP to drop the ext_pip_ prefix and make them standard.


I’d probably want to spec this out as ext_{name-on-pypi}_* to remove a special case on pip in the PEP, to let others do experimentation as well. However this solution is fine with me on both of the Non build_{sdist,wheel} hooks. Although I feel like it kind of defeats the purpose of the prepare_build_files hooks, because I think Thomas’ goal is to not have to support build_sdist from within another sdist, and if he depends on a pip extension (rather than it being an optional speed up like prepare_wheel_metadata) then we either break flit users if we decide it wasn’t worth it and we remove it, or we force other frontends to understand ext_pip_prepare_build_files and we get into the same kind of “everyone is just trying to emulate setuptools” bog that we’re trying to escape.

—
Donald Stufft