[Distutils] Getting more momentum for pip

[Ian Cordasco]

On Fri, Mar 6, 2015 at 5:55 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 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.

+1. This is a problem I have with Flake8. People keep asking for more
command-line arguments because "It's just one more option. It won't
hurt anyone." But Flake8 is another project without a great set of
tests. It would be easy to say "Yeah sure, just this one other option
that only one person has ever asked for" but there's only ever one
person reviewing pull requests - me. It's also not sustainable to keep
adding poorly named command-line flags.

> 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..."

+10

> 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"...

If pip is ever refactored appropriately (which I acknowledge is not a
trivial condition to meet), maybe then pip could consider presenting a
public API, but I think there are currently too many people who
already reach into pip to ignore the need for such an interface.
Perhaps the answer is, as pip is refactored, to create libraries that
are then vendored into pip and that people can install independently
to do that one thing they need to do.

> 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...

There's also how many different replacements for "pip search" on PyPI?

> 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).

So sometimes private cabals need to be made in order to get a basis of
what is reasonable. The WSGI working group tried to do that but that
failed after about a week as more people tried to join the cabal and
were allowed to do so.

> 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...

Go rest. These discussions can exhaust even the best rested of us.