Nix Remains Useful for Side Projects

Nix is a sophisticated package manager.

Nix has a steep learning curve; but those who do take the time to learn it are often enthusiastic about its benefits.

The trade off with Nix is this: you put in effort up front to declaratively describe your software, and then you reap the benefits, such as being able to reproduce the same toolchain setup effortlessly.

One use case I’ve found this useful for has been side projects which I work with infrequently.
Comparing the typical workflow vs the nix workflow of “returning to a sideproject after months/years”:

Typical Workflow When Returning to Sideprojects

e.g. The static site generator for my blog uses Haskell.

So, when I write it, and then return to writing it months/years later, typically some effort to tinkering on it would be getting the system set up again.

If the system package manager (e.g. apt or pacman) doesn’t have the old version of the compiler, then I’d have to build the old code with the new compiler. Likely this left me in the situation where the code was too old to compile; so the project is in a state where I don’t have a working version of it.

Workflow with Nix When Returning to Sideprojects

It’s boring. It works.

With Nix, you can ensure that you’ll end up with the same (old) compiler & libraries which you knew worked previously.

The hard part of working with Nix is more likely to be getting it set up so it works.

I recently updated the version of the Haskell compiler which my site’s static site generator uses.

It pretty much just worked.

The only thing that didn’t work: the Nixpkgs provides several versions of the GHC compiler, and a large set of Haskell packages, but only tests the packages with the current version of the GHC compiler. When I tried newer versions of the compiler than was tested to work, for some reason these didn’t work. – This isn’t really a big deal for my use case; I’m fine with using the current GHC version.

Effort Involved in Setting Up Nix

It’s easier to get something to build on your machine, than it is to build/distribute software.
And it’s easier to use Nix to get a working development environment than to use Nix to describe a package.

It somewhat overstates it to say “writing a package with Nix is hard”. It can be very simple, but it may be very difficult.

I used the approach described in the nixpkgs manual about its haskell support. There’s a nice NixOS Wiki page for Haskell which also describes different ways of using Nix.

Here’s a link to my current Nix package for my hakyll static site generator.

I don’t recall significant pain in setting that up; although I was learning Nix while doing this. e.g. here’s the commit where I upgraded from a shell.nix to a default.nix, added flake.nix, upgraded from GHC 8.4.3 to 9.0.2.

Looking at the my-hakyll-blog.nix file, I don’t love that it duplicates the list of packages from the .cabal file. But, it does work, and I haven’t needed to change it.