Chapter 16 is a curious beast.

It is a list of 17 packages, and information about how to use or configure them.

Some of them make a lot of sense to me: Nginx, Emacs, Complicated packages that, I imagine, there is a lot of configuring to do.

Some of them do not make sense to me. Some of them I have never heard of. ibus-engines.typing-booster. I don’t really think of that as on the same level as, you know, Eclipse. “Cataclysm: Dark Days Ahead.” That’s just… a game. It is the only game listed. Look, I do not know. I’m not sure what the inclusion criteria here is, or if it’s anything beyond “someone put it here.”

Here’s the complete list:

  • Citrix Workspace
  • DLib
  • Eclipse
  • Elm
  • Emacs
  • ibus-engines.typing-booster
  • Kakoune
  • Linux kernel
  • Locales
  • Nginx
  • OpenGL
  • Interactive shell helpers
  • Steam
  • Cataclysm: Dark Days Ahead
  • Urxvt
  • Weechat

Let’s dive in.

Never heard of Citrix Workspace. Never heard of DLib. I have heard of Eclipse, but there is no chance that I will ever use Eclipse again in this lifetime.

We have Elm, but it’s very short, and points to something called elm2nix. Why is this part of Chapter 16? This seems much more at home in Chapter 15. I don’t know.

Then we get to Emacs.

16.5. Emacs

I use Emacs, when I program. Emacs is great, for programming. I’m not using Emacs right now, because Emacs is pretty terrible for prose. I like to write Markdown files, and I find that once you have a Markdown file longer than 20k words or so, Emacs becomes basically useless.

Also Emacs pretty much requires that you hard-wrap your lines, which is something I find abhorrent in prose.

Anyway. When I am using Emacs, I am using something called Spacemacs, which is a sort of configuration manager and set of very good defaults for Emacs. I don’t really know very much about configuring Emacs without using Spacemacs, because I haven’t had to do it in like six years.

Anyway, it seems that I could also choose to configure Emacs with Nix.

The example it gives involves writing a packageOverrides expression that embeds a default.el as a string in a .nix file. Because you don’t want to edit this file in any kind of elisp-mode anyway, do you?

And then a command to copy that file in place.

Look, I don’t know… this seems awful? Maybe it’s possible to just make a normal ~/.emacs.d/init.el and reference these Nix-installed MELPA packages. It’s certainly possible to write the default.el as a separate file and not embed it as a literal string. But… I dunno. I don’t know what the value add is here.

I was sort of expecting something like binaries needed by Emacs. Like, if I want to install racer or haskell-language-server or something in a shell.nix file, in a way that Emacs can see it but it’s not polluting my PATH – how do I do that? The manual does not say. I suppose I have to just globally nix-env -i those packages as usual, and feel a little weird about it.


I dunno. I don’t really see myself switching away from Spacemacs here.

Let’s move on.

There is one sentence about Kakoune, a neat editor that is so close to what I want but tragically broken in many ways that render it unusable and makes me want to write my own.

There are some words about the Linux Kernel, in case you want to make your own Linux Kernel with Nix.

16.10. Nginx

Some words about Nginx:

As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of /nix/store, the hash in the store path is used as the ETag header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.

That’s pretty neat! But also… terrible?

Although I am serving this blog via Nginx on NixOS as we speak, I do not build the blog to my /nix/store, so I do not get this caching behavior.

And I’m not sure I would want to, either: I would need to put each individual file in its own store path in order to actually cache them with the correct resolution. I don’t want to uncache my CSS files just because I fix a typo in some random blog post.

The way my asset caching works right now is the classic thing: putting the hash of the file contents in the file name, and telling clients to cache them forever.

So if I were to regenerate this static site with a default.nix and serve it directly out of my /nix/store – something I thought would be desirable, before reading this – then that would break, and I would need to figure out how to fight Nix to stop doing that. Or I would need to like… put each individual file in the /nix/store, and make a store object that was just symlinks to all the files, with the correct directory structure?

Would the Nix-Nginx integration do the right thing with those symlinks? Would it use the destination hashes for the ETag header?

I don’t know. And I don’t really think I’ll be finding out.

16.12. Interactive shell helpers

Here’s the whole section:

Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn’t have a standard share directory location. This is why a bunch PACKAGE-share scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:

  • autojump: autojump-share
  • fzf: fzf-share

E.g. autojump can then used in the .bashrc like this:

source "$(autojump-share)/autojump.bash"

I take umbrage with “a bunch” being used to mean “2,” but whatever.

Okay. I don’t know what fzf’s shell integration looks like. I am a pretty big fzf user, and have gone so far as to integrate it into my interactive shell’s line-reader, but I don’t know what the default integration looks like.

But anyway, this is a neat trick for “exporting” Nix paths in a nice way.

16.13. Steam

I remember seeing Steam in Nixpkgs while I was looking through uses of buildFHSUserEnv. This section describes some of the reasons why buildFHSUserEnv is necessary, and provides information on how to run Steam in NixOS.

Which seems crazy to me, but then again, running NixOS on a personal computer seems a little crazy to me, and this is a natural thing for someone doing that to want to do.

Anyway, I’m not going to do that, but it’s fun that it’s even possible.

16.14. Cataclysm: Dark Days Ahead

Do you think I can install this on my Mac?

$ nix-shell -p cataclysm-dda

Yeah! It totally worked. With graphics and everything! I didn’t even need to use the curses build.

I have never played Cataclysm: DDA, but I’ve heard very good things. Mayhaps one day I will return to this.

It seems weird that it gets its own little section, including information on how to specify a specific Git revision of the source, how to install mods – if you’re playing a modded Cataclysm: DDA that you assembled via Nix expressions, please get in touch. I feel like you’re using Nix at such a high level that I could probably learn something from talking to you.

Other stuff. Urxvt. Weechat. I don’t know… why I would prefer configuring these in Nix instead of the normal way. But sure.

Then there’s a surprisingly brief section on I would be very impressed if this was sufficient information to install and configure X. But as I am on a Mac, I do not attempt to try.

I know someone who tried to install X using Nix, but not using NixOS. They did not succeed. But they were very brave for trying, I think. I don’t know if they read this section of the manual during the attempt, or whether it helped them. But I like to think that it did.

And that’s the end! Of the chapter and the section. And the blog post. The penultimate blog post. At least in the Nixpkgs series. I think there’s only one post worth of content left. Exciting.