I'm missing something I guess - I don't understand your comment in the context of this claim near the start of the article:

"The root cause of the problem is that distribution package managers and Python package managers ("pip" is shorthand to refer to those throughout the rest of the article) often share the same "site‑packages" directory for storing installed packages."

Having a system venv - managed by the system's package manager - would mean this "root cause" would go away, no?

Of course by poking around the filesystem tree and messing with managed files as root, you could mess up the system venv but that's possible with any installed package.

As I said, a venv is nothing more than a directory + PATH setup. OS already have a dedicated one (in fact, sometimes several). The problem is not that the separation does not exist, the problem is that pip is using the OS real estate.

Creating a new-new separate directory using virtualenv is not going to do anything, just add one more dir to the mix.

>Having a system venv - managed by the system's package manager - would mean this "root cause" would go away, no?

Oh, but you need to explain to pip that it's managed by the system's package manager. Which is what this does with the "EXTERNALLY-MANAGED" file.

And you need to do that because the system's package manager and pip have separate sources - with `pip` you get the packages from pypi, with the system's package manager from its repo.

To supplement, the “root” issue of the whole situation is some users are actively installing things into that system env. So the PEP is providing a mechanism for pip to detect it’s being used to install things into a system env and have a chance to refuse.