[Distutils] Finishing up PEP 517

Nick Coghlan ncoghlan at gmail.com
Fri Jun 16 22:48:35 EDT 2017

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.

The funding dynamics of open source *do* play into those discussions
as a design consideration, since any work done by volunteers needs to
offer some kind of inherent benefit to those volunteers (or they won't
have any incentive to do the work), while work that we expect to be
done by professionals on work time requires some form of justification
as being in their customer's interests (e.g. "more software available
more reliably in the formats that you prefer").


P.S. This "Software distribution, even over the internet, is a more
complex problem than it may first appear" is also why PEP 426 opens
with an attempted overview of the full complexity of the "original
software component publisher to downstream application, service, or
appliance user", and why that's also one of the points I dwelled on in
[1]. Large scale systems engineering is a distinct engineering
discipline for a reason, and it mostly boils down to making smart
decisions about how you divide responsibilities between components.

[1] http://www.curiousefficiency.org/posts/2016/09/python-packaging-ecosystem.html

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list