On Fri, Jun 16, 2017 at 7:48 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 17 June 2017 at 07:48, Nathaniel Smith <njs@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. -n -- Nathaniel J. Smith -- https://vorpus.org