Also note that `pip install` defaults to --user in Debian, and that alleviatesa lot of the "well that didn't work, let me add sudo" urges. Upstream, thisbug tracks that, although it's long standing without much recent progress:https://github.com/pypa/pip/issues/1668IMHO, that's the right direction to go, and I think Donald is philosophicallyaligned (apologies if I'm misreading that, DS!). There are of course plentyof knock-on issues to work out, which is probably why that issue is stillopen.
I think solving this problem (to the degree it can be solved) relies on a multifaceted solution.
One part is certainly defaulting to —user in upstream where it makes sense to do so, so that people are not incentivized by a permission error by default to just throw a sudo in front of their command to make it work.
I think the other part is recognizing that there are valid use cases for ``sudo pip install`` (just like there are for doing ``sudo make install``) and striving to make that function as best we can. The two things I think need done for that are to standardize the “vendor” vs “local” split for site-packages that Debian has, so that the two different sources of a package are not fighting over dropping files into the same directory. The other thing I think that needs to get done is for pip to get better at the concept of overlaying installs on sys.path. We shouldn’t need to uninstall something in the “Vendor site-packages” in order to install it into the “local site-packages” (And similarly for user site-packages).