The main reason is the same why virtualenv exists: if you have Python packages foo, bar, which require different versions of the libbaz library, then sudo pip install bar can update the libbaz version by breaking the foo package waiting for the older version from the system packages.

Hypothetical scenario, but with real packages: let's say you had python-matplotlib Ubuntu package and you updated it to the PyPI version using sudo pip. At first glance, everything is great, you have successfully built the desired schedule. Through a couple of days ago, you found that the search for books in calibre became unstable (you can't find a book for a query that previously found it). After spending some time debugging the problem, if you are lucky, you can localize it to the problem with the version of the pyparsing module used in both calibre and matplotlib.

That is, the problem with sudo pip install matplotlib -U is not that the code with PyPI runs as root (from a security point of view, the problems are worse than with sudo apt-get install python-matplotlib, but not particularly for a typical developer -- you can even check the gpg signature for the downloaded matplotlib wheel, if you want).

The problem is that sudo pip can lead to difficult-to-diagnose problems due to a mismatch between the expectations of packages packaged for apt-get and the versions of packages with PyPI.

That is why, packages that should be particularly independent, such as pip, pkg_resources use their local copy: <package>._vendor.pyparsing.

Sometimes you can use a radical approach and put each utility in its own place virtualenv, for example, using pipx command:

$ pipx install youtube-dl

This allows you to update youtube-dl without touching packages that can be used by other software on the system. And the reverse, updating other packages will not break the youtube-dl command.

The disadvantage of this approach is that when fixing a security hole in a dependency, it will have to be updated in each virtualenv separately.

In essence, by using sudo pip, you take responsibility for that all the package versions and dependencies you have installed will be compatible with the packages installed by the system package manager now and in the future. This is usually the work of the creators of Linux distributions, such as Ubuntu - they try to make the package versions distributed in the distribution work with each other.

By installing pip install --user <package>, you will not break programs that run from another user. By putting in virtualenv, you isolate the system from possible and vice versa (if the --system-site-packages option is not specified when creating) isolate the packages inside virtualenv from changes in the system.

For the convenience of managing virtualenv, you can virtualenvwrapper put.

This is not only true for pip, the use of superuser rights can be caused by the execution of arbitrary code that can harm the system.

If you can't install a package without root, then you probably just incorrectly set the permission for the directory with python packages

For some reason, the correct answer is not written - sudo pip it is tempting to use it when you need to install a python package in a system-wide python installation. At the same time, all of the above is true in the answers - this is simply dangerous, and you can confuse the versions of python that are installed on the system (often there can be both python2 and python3 and other versions coexist on the same node). What should I do? If there is still no way to avoid pip, then first clearly indicate which version of python we are using. we use:

python3 -m pip install ...

Or

python -m pip install ...

The second important thing - if you need to install something in the system python-instead of pip install, it is STRICTLY recommended to use the built-in package manager of the operating system. Why? Because pip install does not prescribe ANYTHING in the system package manager, and the next time you update the system, you will get a mess of packages or they will simply be rewritten.

For example, instead of pip install docker on debian-based, enter apt install python-docker (or apt install python3-docker, if we need to install the package in the third python environment).

In all other cases, it is better to consider installing the package via pip --user install in the user's local environment or virtual env.

Additionally, I can also add that when using pip install -r requirements.txt, there is a regular problem that, depending on the order in which packages are installed, pip may bring different versions of dependent packages (for example, A depends on B version 10, but not later than 11, C depends on B newer than 11 - as a result, we have A, C, and B versions newer than 11). It seems that work is underway in the direction of pip learning how to correctly resolve dependencies (according to the graph), but they are definitely not finished yet.