Hacker News Reader

Comment by kalaksi | Hacker News Reader

I don't get it. Then you just install the tool outside of venv? then it's installed for your user account.

But then all the tool's dependencies have to play nice with the dependencies of all your other unrelated Python-based tools.

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

    alias foo-tool=/home/blah blah/tools/something/env/bin/python -m foo-tool

Or you can make a symlink from your PATH, which is how Pipx does it.

But this is true for anything that isn't statically linked?

Why would static linking be necessary? The virtual environment contains all the needed dependencies, and isolates them from everything else.

ah, right!

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-... .

Reply on news.ycombinator.com