This is my third attempt at writing a response. I’m going to keep it brief(-ish).
- I don’t think the current separation between the core devs and the packaging community is healthy - particularly given that the core devs are removing functionality from the stdlib with the justification that it can be accessed from PyPI. If that’s the justification, “making it possible to access PyPI” is very much a core responsibility.
- Pip is in the stdlib as a bootstrapping mechanism. The pip devs need to be very careful not to abuse our privileged position to extend pip’s scope in a way that’s unacceptable to the core devs and SC. Of course, this argues again for a healthier relationship between the core and the packaging community, because otherwise how does pip know what’s OK?
- IMO dropping pip from the stdlib without replacement is unacceptable. It would damage the experience of far too many users, whose first experience of Python is “install from python.org, use pip to get access to PyPI”. Maybe a streamlined “bootstrap installer” would be a better stdlib component than pip, but who’s going to write such a thing? The packaging community has no motivation, and as you said, the core devs don’t care. Driving the process by the threat that otherwise, pip will be removed without replacement should (I hope) be considered unacceptable.
Other solutions are possible. Making zipapps work better, and shipping a pip (or pipx) zipapp with core Python might be an option, for example. But only if the core devs take a more active interest in the deployment side of the developer experience.