Recently I wrote about how I should use virtual environments for third party programs , and said that I would likely wind up trying pipx . Today, I ran ' pip3 list --user --outdated ', stared at the output of that and ' pip3 list --user ', and decided that my situation in my ~/.local had reached enough critical mass that I was willing to burn it down and start over from scratch. So here are some early notes on pipx , after experimenting with it on my laptop and then switching to it on my home desktop.

In general, pipx is pleasantly straightforward to use in a basic way. Running ' pipx install mypy ' (for example) creates a .local/pipx/venvs/mypy virtual environment, installs things into it, and then creates symlinks in .local/bin to the various programs mypy normally installs. Pipx adds a ' pipx_metadata.json ' file to the venv with various pieces of information about what the virtual environment contains. The venvs appear to be named after the main package you installed with ' pipx install '.

One of my major uses of pipx is to install the Python LSP server , which has two additional things. The first is that you normally install it with some additional pieces specified, not just as a plain package name, for example:

pipx install 'python-lsp-server[rope,yapf]'

Pipx coped with this package specification fine, and called the venv 'python-lsp-server'. The second thing is that there are additional third party plugins you may want to add, like mypy-ls ; these need to be installed into the venv somehow. In pipx, this is done with ' pipx inject <package> ', eg ' pipx inject mypy-ls '.

All of this appears to be recorded in pipx_metadata.json, so I can hope that ' pipx reinstall <...> ' will correctly reinstall all of my Python LSP setup, without me having to remember exactly what I added (I haven't tested this yet, and the manual page is ambiguous).

I'm not sure how you're supposed to look for upgrades to the things you have installed. I suppose one option is ' pipx upgrade ' or ' pipx upgrade-all ' and just letting it do things, and another is to directly ask pip, using ' pipx runpip <package> list --outdated '. The last is probably the only way to find out about dependencies with new versions you may want, which pip doesn't normally upgrade anyway . One brute force way of dealing with the general issues of upgrading programs with pip is to just periodically run ' pipx reinstall <...> ', which should give you a venv that is as up to date as possible at the expense of a certain amount of overhead.

Overall, even if pipx isn't perfect it's a lot better than the mess that was my old ~/.local and actually using it is sufficiently easy and non-annoying that I'm willing to put up with minor flaws if it has them.