3 ms·
It isn't really a question of native or non-native. It's more a question of "under the control of the package manager" vs. "not under the control". You have a
by crdoconnor 10y ago
It isn't really a question of native or non-native. It's more a question of "under the control of the package manager" vs. "not under the control".
You have a similar kind of pain when you have pip and apt trying to manage the system python installation.
- talideon 10y agoIf all you're doing is using pure Python code, there's no issue: you can install what you like, either with the --user flag or into a virtual environment. This situation is nothing like running pip as root.
- crdoconnor 10y agoNo, there are issues. If you install packages that have dependencies on libraries which apt-installed packages depend upon then you can break them. This is all about running code in an uncontrolled environment.
- talideon 10y agoThis is what virtual environments are for, and your solution still uses virtual environments. So no, there aren't. Now, I have a project I'd like to try with per-process mounts of dependencies using unionfs. It'd be a lot of work, and a lot could go wrong, but would solve a lot of problems.
- crdoconnor 10y ago>This is what virtual environments are for Precisely. Virtualenvs solve part of the problem by isolating the python code and its dependencies - but not all of the code. Apparently extending this behavior would cause security issues of an unknown nature...