[Distutils] Getting more momentum for pip

Paul Moore p.f.moore at gmail.com
Fri Mar 6 12:55:38 CET 2015


On 5 March 2015 at 16:38, Marc Abramowitz <msabramo at gmail.com> wrote:
> This makes me think that the folks who review the PRs are overburdened
> and/or the process needs a bit more structure (e.g.: each person thinks
> someone else is going to review the PR and so no one does it).

One thing I, personally, find difficult when reviewing PRs
(specifically feature requests) is the fact that I usually don't
actually have a *need* for the functionality being proposed. It's very
easy for me to say "this doesn't help me personally, so I'll ignore
it", but that is ducking a big part of the responsibility of being a
core committer. But forming a view on something I've no experience of
or direct interest in is *hard*, and takes a lot of time. Discussions
tend to involve a lot of people with strong opinions (e.g. the PR
author) who can't move the change forward, and a few people with
weaker opinions (e.g. me :-)) who can. It's very easy to think "just
accept it because it helps someone". But that's a cop-out and
long-term isn't a sustainable approach.

It's not "thinking someone else will review the PR", it's more making
a conscious decision on how much energy and effort I'm willing to put
into a PR that doesn't have any benefit for me. (And even just
*discussing* a PR can be a lot of energy, it's not easy to politely
explain to someone that you don't think their use case, that they went
to a lot of trouble writing a PR for, isn't worth it).

What would help a *lot* is some sort of agreement on what pip is, and
what its core goals are. Something similar to what it means to be
"pythonic" for the Python language itself. At the moment, I don't
think this is very clearly understood even within the core dev group
(so external contributors have no hope...) And for me, it'd help avoid
the endless debates that often start with the phrase "pip should..."

For example, is the lack of a programmable API an issue for pip? I
think it is, and having people able to write their own tools that use
pip's finder, or its wheel installer, is a (long term) goal for pip,
rather than, say, continually adding more pip subcommands. But I don't
know if that's the consensus. And to my knowledge, no 3rd party PRs
have *ever* been of the form "Encapsulate pip's functionality X in a
clean API so I can use it in my script"...

Or is the "pip search" command a wart that should be removed because
it isn't pip's job to do PyPI searches? There's some low-hanging fruit
if a more focused tool is the goal...

Or should pip give you tools to replicate your current environment
(pip freeze, requirements files)? What about "remove anything *not* in
this requirement file"? Personally, I only use requirements files to
bundle up "install this lot of stuff". I don't write the sort of thing
where a "pin every dependency" philosophy is appropriate, so freeze
isn't something I use. But lots of people do, so what's the workflow
that pip freeze supports?

The problem with discussing this sort of thing is that it's *very*
wide-ranging, and tends to produce huge rambling mega-threads[1] when
discussed in a public list. I'm not advocating any sort of private
cabal deciding the fate of pip, but maybe somewhere where the core
devs could agree their *own* opinions before having to face the public
wouldn't be such a bad thing. That's more or less what I'd expected
the pypa-dev list to be (as a parallel to the python-dev list) but it
doesn't feel like it's turned out that way, maybe because it doesn't
have a clear enough charter, or maybe because there's no obvious
*other* place to direct people to for off-topic posts (like
python-list is for python-dev).

Or maybe grand designs are a distraction in themselves, and none of
the core devs being interested in a PR means just that - not that they
don't have the time, or that the use case isn't valid, or anything
else. Just that they aren't interested, sorry.

[1] Please, don't start a rambling mega-thread from *this* post :-)

Paul

PS I just spend way too long composing this email, and now I'm burned
out. Maybe my time would have been better spent commenting on a couple
of PRs...


More information about the Distutils-SIG mailing list