alt Hacker NewsVirtual environments are an incomplete solution at best. In particular, they really don't help much with the use case of wanting to install a tool: if you're installing a tool and not just setting up a development environment for working on a specific project with its dependencies, then you probably want to make that tool usable without activating its venv. The virtual environment capabilities shipped with Python itself don't really have any affordances for that.
Replies
uvx / uv tool works great for that.
You can `uv tool install your_package`, add a dir to your PATH, and then you can launch the tool appropriately, with it installed in its own venv
I don't get it. Then you just install the tool outside of venv? then it's installed for your user account.
> then you probably want to make that tool usable without activating its venv. The virtual environment capabilities shipped with Python itself don't really have any affordances for that.
The only reason it isn't "usable" is because the wrapper script isn't on your system's path. Unless your tools actually depend on venv-related environment variables being set (for example, because they make subprocess calls and assume that `'python'` will use the currently running Python when they should correctly be using `sys.executable`), which IMX is very rare, you don't ever actually have to activate a venv to do anything with it. In particular, you don't need to activate it to use its REPL; you can instead directly specify the path to its Python executable.
The missing affordance basically looks like `ln -s path/to/venv/bin/tool ~/.local/bin`. Which is a big part of what Pipx does for you. (And once I realized that, I started using Pipx's vendored shared copy of pip: https://zahlman.github.io/posts/2025/01/07/python-packaging-...)