I guess I’m speaking more from the core dev side here, but I personally would/will apply the same logic as I’ve been using for the oft-requested changes to how PATH works on Windows:
We have one chance to break everyone’s defaults, so we need to get it right.
Replacing pip as the default install is such a break, so if we were to go down that path, we’d better be really sure that we’re improving things for users enough to justify the breakage.
I mean, this really is PEP 517, as far as we can do on our side. No “normal” user is going to want to touch anything called “bootstrap”. They’re going to want their IDE to have an opinion about the installer/environment manager.
We keep conflating package install tools with package creation tools, and while both have issues, I don’t think they need to be resolved with each other.
- Should I use venv/virtualenv/pipenv/poetry/PDM/etc.?
- Should I use setuptools/hatch/flit/meson/etc.?
We can answer each one separately, and my gut feel is that most complaints are about the first question, not the second. (It’s not helped when tools try to do both, but they’re not the PyPA ones, so outside our scope.)
FWIW, I’ve never had any colleagues complain about having to use pip. It’s usually the virtual environments that cause the angst, not installation. Similarly with the educators I’ve spoken to (and hence why I put up 582 in the first place, where the pip integration is crucial and supplanting today’s virtual environments is the point). Even conda environments are what people don’t like, not the install command.
I’m not sure how best to validate this with users, but it does seem that fixing “I want to install these packages just for this project” would go the longest way to helping.