[thesuperbigfrog]

I think it really comes down to Python not having a chosen way to handle package management as well as Python being dependent on the underlying C libraries and compilers for the given platform.

Since Python did not prescribe a way to handle it the community has invented multiple competing ways to solve the problem, most of which have shortcomings in one way or another.

To further add to the confusion, most Linux and Unix-based operating systems (Linux, MacOS, etc.) have their own system Python which can easily get fouled up if one is not careful.

This is one place where Java's use of a virtual machine REALLY shines. You can build an uberjar of your application and throw it at a JVM and (barring JNI or non-standard database drivers) it just works. There is also usually no "system Java", so there is nothing to break along those lines.

[yjftsjthsd-h]

> barring JNI

Exactly. It's not Python's only problem, but far and away the most painful snags I've hit with packages is when they use C code, and thereby drag in the whole system. "I'll just `pip install` this- Oh, I need to install foo-dev? Okay, `apt-install foo-dev`... oh, that's in Ubuntu but not Debian? Well this is gonna be fun..." Now I trend a bit more exotic in my systems (NixOS, Termux, *BSD, ...) but if my Python were just Python it would just work so long as I have a working Python install; in practice that's rarely enough.

[heavenlyblue]

You’d need to install foo-dev in the context of any language that supports c extensions.

[throwawayjava]

> There is also usually no "system Java", so there is nothing to break along those lines.

Oh, but there is :( `jenv shell 1.8` is muscle memory for me now.

[thesuperbigfrog]

You can have multiple JVMs or JDKs installed, and therefore the need to change environment variables depending on your use cases, but I was referring to Java being part of the operating system in the same way that Python is part of some operating systems, for example several Linux distributions (Fedora, RHEL, and practically all derivatives).

[int_19h]

Isn't it still just a package on Red Hat distros? A base system package, granted, because some system tools are written in Python.

But in any case, it just becomes one more version of Python to consider. If you're already dealing with multiple versions, what difference does it make?

[thesuperbigfrog]

It is "just a package" in the sense that there are RPMs for Python, but many system management tools are Python scripts that assume you have Python and specific Python libraries installed so that everything will run correctly.

If you have root privileges and you run "sudo pip" commands you might accidentally break the specific Python dependencies that the system scripts rely on. See https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

There's no issue with using the system Python, but any Python packages should be installed via yum or similar Red Hat / Fedora tools and not pip.

Note that the newer versions of RHEL have created developer-specific tool packages to separate the system packages from developer packages. This allows the developer packages to get upgraded quickly so developers have nee, shiny tools without breaking the compatibility that the base system needs to keep running.

[fock]

I'm not sure how people manage to "foul up" their system python, but you are doing something extremely wrong, when giving random devtools root access to transform a typical (non NixOS and friends) production environment (your workstation!) into a custom development environment.

Given that: are you sure problems arise around pure python-packages (which generally have a well enough forward compatibility), or is the problem with all the cool "machine-code"-embedded packages (which are a lot!)? And yeah, these might indeed break randomly, when installed on different systems of different time-periods. But that's a problem all binary packages have!