Some early notes on using pipx for managing third-party Python programs

October 5, 2021

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.

Written on 05 October 2021.
« The "why" problem with on-host (host-based) firewalls on your machines
The OpenSSH server has limits on what user authentication you can use »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Oct 5 23:59:15 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.