Tagged with: nix

Nix: Day to Day Usage

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.

Integrating Esbonio with Neovim Using Nix

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.

Since 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.

My Next Steps with Nix: Overlays

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 esbonio repo.

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.

My First Steps with Nix

Nix, depending on the context, can refer to a programming language, a package manager or a Linux Distro.

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.