This blog post marks a change in my usage of Nix, I’m (just!) past the point of trying to get something to work and now starting to incorporate it into some of my regular workflows. So instead of trying to accomplish some major task, this post is a small collection of things I’ve learned over the past few weeks.
So far I’ve been learning how to use Nix by trying to package and define development shells for esbonio (see here if you are interested). While useful, the end result is not too dissimilar to what you can get with standard Python tooling. Indeed, the main reason I started looking into Nix was the promise of it being able to manage more than just Python libraries.
esbonio is a language server, it would be useful for Nix to create standardised environments where the language server is pre-configured for a given editor - great for debugging and demos!
In this blog post I try to define an environment in which Neovim is installed and configured to use the
esbonio language server for reStructuredText files.
It turns out there were a few issues with the setup I put together in my previous post. This time I try and resolve them and get to the point where I have working overlays for both pytest-lsp and esbonio.
Last time, I experimented with writing a flake that defined development environments for the esbonio package spanning multiple Python versions.
During that process I also packaged pytest-lsp using an ad-hoc nix expression as part of the
In this post I look into writing a similar flake for the
pytest-lsp package itself, but this time using overlays to override and extend the nixpkgs package set.
If you are interested, you can find the final version of the code here.
Personally, I’m most insterested in the package manager aspect and the promise of it being able to create declarative, reproducable development environments. With a configuration file and the nix develop command you can activate a kind of “virtual environment” that contains not just your Python packages - but any program defined by the configuration!
I find that idea particuarly exciting when working on a language server like esbonio, since it needs to be able to work against a variety of Python versions, Sphinx versions, as well as various code editors and all their versions! Having the ability to define a particular configuration and have some tool automatically recreate it would be amazing.
But I’m getting ahead of myself, let’s see if I can get to a point where I can easily test
esbonio against a range of Python versions.