It’s probably unsurprising that I agree with pretty much everything written in @pradyunsg 's excellent post. In fact, the Github comment of mine he dug up from 2019 could have easily been posted word for word in this discussion and still made complete sense.
One thing I will disagree with on, is this statement:
We still don’t have agreement that this is the direction that we, as a community, want pip to go.
If we include the wider Python community, I think there is heavy agreement on this given that:
- The vast bulk of people are still using pip even though tools like poetry, pdm, hatch exist.
- By far the number one ask for like 5-10 years now has been to provide a more unified experience.
I can’t find a way to reconcile those two facts with each other, without coming to the conclusion that most of our users area already in agreement that this is the direction they want pip [1] to go.
I think where the disconnect is, that the people working on these tools can’t come to agreement that this is the direction we want to go. I think there is a lot of reasons for that, we’re best positioned to understand the nuances of the various tools and to take advantage of the power of the unix philosophy, we’re all working on different tools within the ecosystem and have a vested interest in what’s best for our own projects, dictating ecosystem level, non technical decisions is hard and we’ve been loathe to do that.
Ultimately, I think what it comes down to is we’ve gotten pretty good at using the PEP process to make technical decisions about interoperability standards [2], but we’re terrible at using it for anything else and we don’t have a real alternative for making decisions otherwise. That means that anytime we have this discussion, we largely just sit around talking about what we could or should do with no actionable items on how we’re going to come to an agreement.
So here’s what I’m going to propose:
Interested parties write a PEP on how they think we should solve the “unification” problem within some time frame, all of these PEPs will have the same set of PEP-Delegates, the various proposals will be discussed just like any other PEP, then the PEP-Delegates will pick one and that’s the direction we’ll go in [3]. If they are unable to come to an agreement, then it will get kicked up to the SC to make a choice.
My recommendation is that we do something a little unorthodox and instead of having a singular PEP-Delegate, we instead have a team of 3 of them, who will together select the direction we go in. My rationale here is that this is our first time making a decision quite like this, it’s going to be a decision with a large impact, and there is no one singular person who could make this decision who isn’t biased in some way.
Unfortunately, since we don’t have a good way to make these decisions, we also don’t have a good way to make a decision on how to make a decision. So I’m going to propose that we wait two weeks, and if there isn’t a large outcry, then we just move forward with this idea.
I don’t think they actually care if it’s pip or not, what they actually care is that the tool that comes with Python should go in this direction. Obviously that tool is currently pip, so by that nature they have agreement that it should be pip. Of course another option is that we get agreement from Python Core that another tool should be bundled within Python. ↩︎
Also for large decisions for PyPI itself, but that’s not related. ↩︎
Obviously we have no real enforcement mechanism here, if some project disagrees with the ultimate choice made, they’re free to go their own way-- and that’s a good thing. We’re not looking to create the one true tool to rule them, just to provide the default tool. Other tools may still exist and people can still use them, but defaults matter. ↩︎