[Distutils] Finishing up PEP 517

Nathaniel Smith njs at pobox.com
Fri Jun 16 23:15:31 EDT 2017

On Fri, Jun 16, 2017 at 7:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 17 June 2017 at 07:48, Nathaniel Smith <njs at pobox.com> wrote:
>> 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.
>> What do you think?
> pip's needs here aren't unique to pip - they're just "system
> integrator" needs, rather than "software developer" needs.
> It's fairly common for system integrator needs to seem like pointless
> complexity to folks more focused on addressing the "single component
> publisher (aka software developer)" case, but that's part of why we
> have the PEP process: to encourage us to figure out the best place for
> complexity to live in order to advance the overall Python ecosystem,
> rather than trying to convince ourselves that the underlying
> complexity doesn't exist.

I'm not making an argument that the complexity doesn't exist or that
pip is the only project that matters; I'm arguing that it's risky to
standardize things before we've really hit the problem, because we
might not fully understand it yet. Which is a truism :-). But
sometimes you don't have much choice. The real suggestion is hey,
maybe in this case there's a way to get these
important-but-not-fully-understood issues off the critical path for
PEP 517 without losing our chance to handle them later.


Nathaniel J. Smith -- https://vorpus.org

More information about the Distutils-SIG mailing list