3 ms·

It's already the case, that's why you see some mistaken tutorials telling you to "sudo pip install". A venv is just a dir and some path, and your os already ha

It's already the case, that's why you see some mistaken tutorials telling you to "sudo pip install". A venv is just a dir and some path, and your os already have some dedicated to their own python install, even if it's not called a venv, but something like dist-packages + manual PATH fudging. This proposal makes the distinction clearer by putting safeguard to NOT to mess up with the system stdlib. You should be using "--user" or a local venv, and "-m" to call commands. See my other comments for more tooling.

derriz 5y ago
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.
- faho 5y ago
  >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.
  - uranusjr 5y ago
    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.
- BiteCode_dev 5y ago
  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.

derriz 5y ago

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.

faho 5y ago
>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.
- uranusjr 5y ago
  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.
BiteCode_dev 5y ago
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.