Uv is the best thing to happen to the Python ecosystem in a decade

I would probably use something like this: https://stackoverflow.com/questions/17803829/how-to-customiz...

Because it being available in the system environment could cause problems for system tools, which are expecting to find something else with the same name.

And because those tools could include your system's package manager (like Apt).

> So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it.

I assume you're referring to the new protections created by the EXTERNALLY-MANAGED marker file, which will throw up a large boilerplate warning if you try to use pip to install packages in the system environment (even with --user, where they can still cause problems when you run the system tools without sudo).

You should read one or more of:

* the PEP where this protection was introduced (https://peps.python.org/pep-0668/);

* the Python forum discussion explaining the need for the PEP (https://discuss.python.org/t/_/10302);

* my blog post (https://zahlman.github.io/posts/2024/12/24/python-packaging-...) where I describe in a bit more detail (along with explaining a few other common grumblings about how Python packaging works);

* my Q&A on Codidact (https://software.codidact.com/posts/291839/) where I explain more comprehensively;

* the original motivating Stack Overflow Q&A (https://stackoverflow.com/questions/75608323/);

* the Python forum discussion (https://discuss.python.org/t/_/56900) where it was originally noticed that the Stack Overflow Q&A was advising people to circumvent the protection without understanding it, and a coordinated attempt was made to remedy that problem.

Or you can watch Brodie Robertson's video about the implementation of the PEP in Arch: https://www.youtube.com/watch?v=35PQrzG0rG4.

But the main reason shouldn't be the "lockfile". I was replying to the parent comment mainly for that particular thing.

This whole discussion has the same vibes like digital photography 15 years ago. Back then some people spent more time on discussing the tech spec their cameras than takin photos. Now some people spend more time on discussing the pros and cons of different Python environment management solutions than building real things.

The last time I had to touch one of my dockerized environments was when Miniconda and Miniforge were merged. I said the agent "fix the dockerfile", and the third attempt worked. Another time, one dependency was updated and I had to switch to Poetry. Once again, I said the agent "refactor the repository to Poetry" and it worked. Maybe because all my Python package versions are frozen and I only update them when they break or when I need the functionality of the new version.

Whenever this topic pops up in real life, I always ask back what was the longest time they managed the same Python service in the cloud. In the most cases, the answer is never. The last time someone said one year. After a while this service was turned into two .py files.

I don't know. Maybe I'm just too far away from FAANG level sorcery. Everything is a hammer if all you have to deal with are nails.

Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other version on the system).

Or the package manager itself has some way to figure that out through its config file.

Or there is a package manager launch tool, just like pyenv or whatever, which does that for you.

In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career.

Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity.

CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.