I agree, without some fundamental changes to how pip is maintained, this would be a very long process. (And I’m not sure what precisely you cover with the term “governance”, but one constraint we’d have to look very hard at is “willingness to break existing users for the sake of future growth”)
Speaking as another pip maintainer, I have a slightly different view than @dstufft. I think that he’s absolutely right that growing pip into the “unified tool” role is a great way to sidestep all of the questions about what tool to bless. But the difficult question for me is how do we get there from here.
Users want a unified tool. OK, but when do they want it? In 3-5 years? Maybe we could get pip to the point of being that tool in that sort of time period. In 6 months? Not a chance. Maintainer bandwidth is definitely one problem (and I can attest to the fact that working on pip, in particular the “maintenance” side, is very draining[1]). Other issues are the various legacy cases we have to handle - removing the “direct invocation of setup.py” code path has been a multi-year project blocking many new developments, similarly for the new resolver, and the idea of a “plugin” architecture and a stable API, which if implemented would help immensely with adding new commands/functionality. And there’s the whole scope question - while we might agree in principle with “becoming the unified tool”, each new command would need discussion and agreement. There’s been a long (again, multi-year) discussion on a pip run command that runs a script with its dependencies available in a temporary environment, for example.
In addition, this could involve significant bootstrapping issues for pip. If we offer new functionality, do we write it ourselves, or do we vendor an ever-increasing number of 3rd party modules? Do we need to re-architect pip to have a small “bootstrap” version that can self-extend to add functionality without vendoring? How else do we isolate our dependencies from the user’s? How will vendoring further libraries impact Linux distributions, who already need to decide how or if they devendor pip? Having a single centrally-installed pip might help here (it’s what other tools do) but when I introduced the --python option, I asked about that and the idea was not well-received (some objections were simply inertia, but there were enough genuine problems that the idea was dropped - specifically the fact that subprocess.run([sys.executable, "-m", "pip"]) is our supported method of running pip from within your code).
To repeat, I agree with @dstufft that growing pip to fill the “unified tool” role is a great option. But I don’t think we should underestimate the challenges.
Equally, though, I think people offering other projects as the “unified solution” may have underestimated the impact on them if they suddenly became the recommended tool and gained a userbase the size of pip’s (the one exception here may be Poetry, which already has a sizeable community, albeit a lot smaller than pip’s).
One final point - we’ve been gradually expanding pip’s capabilities for years now. And pip is already the standard tool shipped with Python. So in some senses “make pip the recommended tool” is the “do nothing” option - and could well be perceived by users as exactly that. If we took this route, how would we explain to users that we’d listened to their concerns and were giving them what they’d asked for?
And I’d be against adding maintainers who only wanted to work on shiny new stuff and ignore the maintenance side, for the record. ↩︎