3 ms·

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

tdeck 1y ago
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
- kalaksi 1y ago
  ah, right!
- timcobb 1y ago
  But this is true for anything that isn't statically linked?
  - zahlman 1y ago
    Why would static linking be necessary? The virtual environment contains all the needed dependencies, and isolates them from everything else.
- zahlman 1y ago
  Or you can make a symlink from your PATH, which is how Pipx does it.
swiftcoder 1y ago
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
- zahlman 1y ago
  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?
  - swiftcoder 1y ago
    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.
    - zahlman 1y ago
      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 https://news.ycombinator.com/item?id=45467514 . It's also covered in https://zahlman.github.io/posts/2024/12/24/python-packaging-1/ https://zahlman.github.io/posts/2024/12/24/python-packaging-... .

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

kalaksi 1y ago
ah, right!
timcobb 1y ago
But this is true for anything that isn't statically linked?
- zahlman 1y ago
  Why would static linking be necessary? The virtual environment contains all the needed dependencies, and isolates them from everything else.
zahlman 1y ago
Or you can make a symlink from your PATH, which is how Pipx does it.

swiftcoder 1y ago

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

zahlman 1y ago
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?
- swiftcoder 1y ago
  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.
  - zahlman 1y ago
    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 https://news.ycombinator.com/item?id=45467514 . It's also covered in https://zahlman.github.io/posts/2024/12/24/python-packaging-1/ https://zahlman.github.io/posts/2024/12/24/python-packaging-... .