On 5 March 2015 at 16:38, Marc Abramowitz <[email protected]> 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... _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
