> On Jun 16, 2017, at 5:48 PM, Nathaniel Smith <n...@pobox.com> wrote:
> 
> On Fri, Jun 16, 2017 at 2:08 AM, Thomas Kluyver <tho...@kluyver.me.uk 
> <mailto:tho...@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



_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to