What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.
Exactly, and this is why we use virtual environments. Which then get dumped on by other people. People can't have it both ways, but they already have all the choices in Python's ecosystem. They just complain, because they are not aware how they can do it their way and didn't invest the time to nail down the workflow they like, or their workflow idea is self-contradictory.
> The fact that everything pollutes the global environment
This is not anything like a fact. For three years now (since the 3.11 release) Python distributions on Linux have in fact taken special measures to prevent the user from using tools other than the system package manager to install into the global environment. And for thirteen years (since the 3.3 release) Python has offered standard library functionality to create isolated environments specifically to avoid that problem. (And that functionality is based on a third party library with public releases going back eighteen years.)
Pip is designed around giving you the freedom to choose where those environments are (by separately creating them) and your strategy for maintaining them (from a separate environment per-project as a dev, to a single-environment-still-isolated-from-the-system for everything as a data scientist, and everything in between).
I've never quite forgiven python for the time I tried to update it using yum, it failed which is then broke yum - not a fun place to end up.
Treating python as a project level dependency rather than a system level dependency is just an excellent design choice.
> Treating python as a project level dependency rather than a system level dependency
Nobody is treating Python as a project level dependency. Your Linux distro treats it as a system level dependency, which is exactly why you encountered the problem you did.
When you create a virtual environment, that does not install a Python version. It just makes symlinks to a base Python.
Building Python from source, and setting it up in a way that doesn't interfere with the package manager's space and will cause no problems, is easy on major distros. I have access to over a dozen builds right now, on Mint which is not exactly a "power user" distro (I didn't want to think about it too much when I initially switched from Windows).
System package management is a mess in the first place, if you have a program that uses python then all the packages that it uses need to be installed globally, so you have python packages bundled as system packages which can conflict with that same package installed with pip.
> if you have a program that uses python then all the packages that it uses need to be installed globally
Only if that "program that uses Python" is itself provided by a system package for global installation.
> so you have python packages bundled as system packages which can conflict with that same package installed with pip.
Right; you can choose whether to use system packages entirely within the system-package ecosystem (and treat "it's written in Python" as an irrelevant implementation detail); or you can create an isolated environment so as to use Python's native ecosystem, native packaging, and native tools.
I don't know why anyone would expect to mingle the two without problems. Do you do that for other languages? When I tried out Ruby, its "Bundler" and "gem" system was similarly isolated from the system environment.
My sentiment coming to Python after getting used to the DX of Node
https://uploads.dailydot.com/2024/04/damn-bitch-you-live-lik...
My exact reaction when I visit front-end-land. It always surprises me that you can't just leave a project alone for some time, get back to it and continue where you left off. There are always a couple of days of getting the thing to work again, then figuring out how everyone is doing things now, because apparently that has to change every few months.
While I don’t do frontend and don’t want to defend that mess, I think that locking a specific version for each dependency would solve this
Uv allows you to lock versions too. And creates a .venv inside the project which, I guess, is similar to the node_modules directory.
For sure, I was referring to the state of python before uv. Specifically projects not being self-contained, easily portable, etc
You could already do these things before, you just spent much more time twiddling your thumbs waiting for lock files to be resolved
I'm not talking about the global environment. I want to be able to have whatever environments I want. But my point is that the environments are not in a 1-1 relationship with "projects".