Personally, I’m not as sure that this is the direction I want pip to go in. Given that a significant number of tools (in particular, the existing workflow tools) use pip in a subprocess to install packages, I think there’s a genuine need for something that acts as a (relatively!) streamlined package installer, and doesn’t do workflow (i.e., it doesn’t compete with the tools that want to embed it).
For now, at least, that tool is pip - and I think we should be cautious about changing the scope of pip without ensuring that there’s still an acceptable “embeddable installer” option.
This would have to be proposed as a PEP to CPython itself, similar to how pip was added in PEP 453. The CPython core devs (and the steering council in particular) would have to agree to this.
It’s also worth noting that the proposal to include pip was explicitly to “bootstrap” the packaging ecosystem. So pip was only proposed as a way to allow people to install whatever tool(s) they actually wanted to use, rather than as the tool we expect everyone to use. So adding a new workflow tool changes the arguments for having pip in the stdlib, and that’s something else that would need to be covered in any PEP that proposed a new tool. Specifically, if tool X is added to the stdlib as the official solution, there’s no longer any need for pip to be in the stdlib. Except as a dependency, but would it be acceptable to ship a tool with dependencies in the stdlib[1]?
Clearly the ecosystem has changed since PEP 453, and it’s perfectly reasonable to suggest that what’s in the stdlib changes to reflect that. And the PyPA (or longer term, the packaging council) is in a good position to set the parameters for such a proposal. Although I doubt there’s a realistic possibility of anyone (council, PyPA or community) being able to come to a decision on which workflow tool is going to be blessed as the “official answer”. We’ve had way too many unproductive discussions on this in the recent past for me to think there’s anything even remotely like a consensus.
Personally, I still think that the idea of having a simple installer in the stdlib, that people can use to install their workflow tool of choice, is the right approach[2], but I’m aware that this view is relatively uncommon these days.