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 <mailto: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