Some early notes on using pipx for managing third-party Python programs
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
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
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 '
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>',
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
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.