Those VMs are isolated from the network, but we can have partial control over it via the .spec file. This allows the call to some external "helpers" scripts that are described as a build only dependency, and that create a Python venv, and help with the re-allocation (maybe in /usr/local, or /opt, for example)
The cool thing is that the venvs are self-contained by a lot, including the Python (we can include it inside the venv, so is de-attached from the system Python version, but this is totally optional) and the system libraries (.so) that are both dependent of the Python version and the system libraries.
A non-trivial example is this: https://build.opensuse.org/project/show/systemsmanagement:sa...
If you check the subprojects you will see the venv for Fedora, openSUSE, Ubuntu and others.
If the build system is minimally powerful, you can do really crazy stuff. For example, there is one member of the team that is thinking on wrapping the final venv into SquashFS, to decrease the size and simplify the installation.
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.
"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.
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.
Creating a new-new separate directory using virtualenv is not going to do anything, just add one more dir to the mix.