What really annoys me is they purposely broke per-user and local installation. Fine, system wise installation isn’t a good idea when it’s already managed by another package manager, but user installation is my domain.
The reason they did this is because a package installed by the user can be active when a system tool is called and break the system tool. The distro developers went “Oh, we should force all user code into venvs so that our code is safe”.
Completely and utterly backwards. The protected code needs to be inside the defensive wall. The user should be allowed to do anything in the knowledge that they can’t inadvertently change the OS. When a system tool is called it should only have system libraries on it’s Python Path.
You still have the option to choose not to use a venv and risk breaking your user space.
The changes make this harder to do it by accident by encouraging use of a venv. Part of the problem is that pip install --user is not exactly in the user space and may in fact break system packages, and as you wrote, the user shouldn’t be able to inadvertently change the OS.
Makes more sense and I agree, especially with the apparent ease of pip install --user. But there should be no barriers when the root user is used with pip install --system.
What really annoys me is they purposely broke per-user and local installation. Fine, system wise installation isn’t a good idea when it’s already managed by another package manager, but user installation is my domain.
The reason they did this is because a package installed by the user can be active when a system tool is called and break the system tool. The distro developers went “Oh, we should force all user code into venvs so that our code is safe”.
Completely and utterly backwards. The protected code needs to be inside the defensive wall. The user should be allowed to do anything in the knowledge that they can’t inadvertently change the OS. When a system tool is called it should only have system libraries on it’s Python Path.
You still have the option to choose not to use a venv and risk breaking your user space.
The changes make this harder to do it by accident by encouraging use of a venv. Part of the problem is that
pip install --useris not exactly in the user space and may in fact break system packages, and as you wrote, the user shouldn’t be able to inadvertently change the OS.Makes more sense and I agree, especially with the apparent ease of
pip install --user. But there should be no barriers when the root user is used withpip install --system.So the problem here is that you can inject code into a system python process because they run with the user’s python install location on their path.
They’ve fixed the wrong “root cause”.