That requires you to be running the right version of python at the system level, and for all your installed tools to have compatible package versions. It doesn't work very often for me
What sorts of things are you installing that you "often" need to care about having the "right" version of Python? It's normal in the Python ecosystem that packages explicitly support every non-EOL Python version. Numpy already has wheels out for 3.14. And even if you use an older Python, the older compatible Numpy versions don't go away.
Can you give a concrete example of an installation you attempted that failed?
It's rarely the python version itself that is the problem (provided everything supports 3.9+ or similarly recent versions).
The package versions are however fraught - our machine learning codebase at work only was stuck on the 1.x versions of numpy for more than a year, as scipy and ultralytics both took forever to upgrade, and that prevented us adopting packages that depend on the 2.x numpy.
The entire point of the virtual environments is that you can have both on your system, as needed, for separate projects.
But the language isn't designed to support multiple versions of the same library in the same runtime environment. If you get them both to load (and there are a lot of ways), they are different libraries (actual different module objects) with different names (or the same name in different namespaces). Packaging tools can't do anything meaningful about this. I write about this on HN more often than I'd like; see e.g. https://news.ycombinator.com/item?id=45467514 . It's also covered in https://zahlman.github.io/posts/2024/12/24/python-packaging-... .
One thing you can do (I'm not saying it's user friendly) is set up the tool in a virtualenv and then set up an alias like