Python has always struggled with distribution maintainers that just don’t get it.
Python barely survived becoming the default scripting language on Red Hat and other Linux distros which was a major obstruction to the Python 3 transition. If the new cohort of pandas and scikit-learn users had not been such a force of nature we”d be talking today about Python the way we do about Perl.
Not installing venv is a serious crime on the part of Debian as beginners don’t need any more excuse to trash their system with site-local directories and other wrong answers for how to manage packages in Python.
People just want to get things done. If they can get away with two commands instead of six they will, which is why I think poetry has gotten more adoption.
The word package is overloaded. There is a Debian package and there is a Python package.
If somebody wanted to package a modern Python application as Debian package they’d have to make a Debian package that contains several Python packages maybe as a venv or executable wheel, it is a solvable problem but a bit like comparing tic tac toe to 12d chess with supersymmetry in terms of the ambition of Linux distros if not the difficulty.
If you installed python packages as debs without any isolation you'd never be able to install two applications that depended on different versions of the same Python package.
The best thing about Java is that it is so xenophobic that nobody expects to have a working Java runtime installed with the OS so you never have to deal with a broken runtime installed with the OS. JAR files are remarkably self-sufficient so "write once one anywhere" is way closer to the truth than it is on "DLL Hell" platforms like Windows and Linux.
It takes more work to create and push a Debian package. Yes. But once it's done, it's DONE, and you never talk about it again. This whole article and thread can disappear, which is a MASSIVE time savings. The "DLL hell" you're referring ot exist on platforms that don't have package management, which notably does not apply to Linux, in general.
The funny part about Java is that "Enterprise Java" used to depend a lot more on things being in the base application server, and because that was, as usual, complete hell, it now went the complete other way and microservices will often "just bundle the entire application server" in the uberjar as a result.
Because people are lazy and the right thing must be easier then the wrong thing. The main project in Python now (going well) is removing the footguns, and
pip install —-user
Is one of them. If users don’t have venv they will trash their Python installation almost right away and probably join the many people who’ve left Python.
> Isn’t it considered best practice not to use brew to install Python for exactly this reason?
The only time I've ever had a big mess with broken Python installs was after using brew on Linux - luckily killing off brew brought the system Python back fine. I'll grudgingly put up with brew on a Mac out of necessity, but keep it away from Linux.
Not that I would truly recommend to use brew on linux as there are better alternatives - docker images, distrobox with a rolling distro for newer python, or LTS distro to keep an older version, pyenv etc, but..
If you've had a problem with brew, it was most certainly caused because you sourced it in your .profile, .bash_profile or .zprofile. Never do that.
It's what brew's homepage recommends, but it can break a LOT of things and not just python. Brew should be in the $PATH only when you need it, from your current instance of interactive shell used for development, and not login-wide. The brew version of various pieces of software should not ever be able to take over what your system has or very unpredictable things will happen.
I avoid brew whenever possible, partially because it does weird stuff just to avoid installing things as root. MacPorts is nice but doesn't always have the port you want. Something like Python with a convenient .pkg download directly from python.org makes the choice obvious.
That said, some Python packages rely on native code that you might find yourself brew-installing. That can be a nightmare.
I’ve always seen it recommended to use pyenv or just download directly from Python.org instead.