3 ms·

If everything's native[1], whether you're talking about Python, Java, or any other language, you're golden. The issue arises when you're calling out to somethi

If everything's native[1], whether you're talking about Python, Java, or any other language, you're golden. The issue arises when you're calling out to something written in, say, C. You'll have the same pain in java if you start using JNI to call across the JVM boundary. It just crops up more in Python because C extensions get used a lot in Python. Addendum: [1] By this, I mean within the boundaries of the runtime environment and not using things like Python's C extension API or JNI. 'Native' is a poor choice of words.

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 ago
  If 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 ago
    No, 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 ago
      This 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...
dkersten 10y ago
My point was that I've never had to care if a jar contained C libraries or not. Some do, many don't, but I've never had to care. Maybe I've just been lucky. I suppose it could have been a fat-jar thing: if the jar contains its non-java dependencies for my platform, then everything just works. If the native libs are separate, then sure, its a similar issue as described elsewhere here.

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 ago
If 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 ago
  No, 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 ago
    This 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...

dkersten 10y ago

My point was that I've never had to care if a jar contained C libraries or not. Some do, many don't, but I've never had to care. Maybe I've just been lucky. I suppose it could have been a fat-jar thing: if the jar contains its non-java dependencies for my platform, then everything just works. If the native libs are separate, then sure, its a similar issue as described elsewhere here.