xesite/blog/nixos-desktop-flow-2020-04-25.markdown

---
title: "My NixOS Desktop Flow"
date: 2020-04-25
series: howto
---

# My NixOS Desktop Flow

Before I built my current desktop, I had been using a [2013 Mac Pro][macpro2013]
for at least 7 years. This machine has seen me through living in a few cities
(Bellevue, Mountain View and Montreal), but it was starting to show its age. Its
12 core Xeon is really no slouch (scoring about 5 minutes in my "compile the
linux kernel" test), but with Intel security patches it was starting to get
slower and slower as time went on.

[macpro2013]: https://www.apple.com/mac-pro-2013/specs/

So in March (just before the situation started) I ordered the parts for my new
tower and built my current desktop machine. From the start, I wanted it to run
Linux and have 64 GB of ram, mostly so I could write and test programs without
having to worry about ram exhaustion.

When the parts were almost in, I had decided to really start digging into
[NixOS][nixos]. Friends on IRC and Discord had been trying to get me to use it
for years, and I was really impressed with a simple setup that I had in a
virtual machine. So I decided to jump head-first down that rabbit hole, and I'm
honestly really glad I did.

[nixos]: https://nixos.org

NixOS is built on a more functional approach to package management called
[Nix][nix]. Parts of the configuration can be easily broken off into modules
that can be reused across machines in a deployment. If [Ansible][ansible] or
other tools like it let you customize an existing Linux distribution to meet
your needs, NixOS allows you to craft your own Linux distribution around your
needs.

[nix]: https://nixos.org/nix/
[ansible]: https://www.ansible.com/

Unfortunately, the Nix and NixOS documentation is a bit more dense than most
other Linux programs/distributions are, and it's a bit easy to get lost in it.
I'm going to attempt to explain a lot of the guiding principles behind Nix and
NixOS and how they fit into how I use NixOS on my desktop.

## What is a Package?

Earlier, I mentioned that Nix is a _functional_ package manager. This means that
Nix views packages as a combination of inputs to get an output:

<center>![A nix package is the metadata, the source code, the build instructions and
some patches as input to a derivation to create a
package](/static/blog/nix-package.png)</center>

This is how most package managers work (even things like Windows installer
files), but Nix goes a step further by disallowing package builds to access the
internet. This allows Nix packages to be a lot more reproducible; meaning if you
have the same inputs (source code, build script and patches) you should _always_
get the same output byte-for-byte every time you build the same package at the
same version.

### A Simple Package

Let's consider a simple example, my [gruvbox-inspired CSS file][gruvboxcss]'s
[`default.nix`][gcssdefaultnix] file':

[gruvboxcss]: https://github.com/Xe/gruvbox-css
[gcssdefaultnix]: https://github.com/Xe/gruvbox-css/blob/master/default.nix

```nix
{ pkgs ? import <nixpkgs> { } }:

pkgs.stdenv.mkDerivation {
  pname = "gruvbox-css";
  version = "latest";
  src = ./.;
  phases = "installPhase";
  installPhase = ''
    mkdir -p $out
    cp -rf $src/gruvbox.css $out/gruvbox.css
  '';
}
```

This creates a package named `gruvbox-css` with the version `latest`. Let's
break this down its `default.nix` line by line:

```nix
{ pkgs ? import <nixpkgs> { } }:
```

This creates a function that either takes in the `pkgs` object or tells Nix to
import the standard package library [nixpkgs][nixpkgs] as `pkgs`. nixpkgs
includes a lot of utilities like a standard packaging environment, special
builders for things like snaps and Docker images as well as one of the largest
package sets out there.

[nixpkgs]: https://nixos.org/nixpkgs/

```nix
pkgs.stdenv.mkDerivation {
  # ...
}
```

This runs the [`stdenv.mkDerivation`][mkderiv] function with some arguments in an
object. The "standard environment" comes with tools like GCC, bash, coreutils,
find, sed, grep, awk, tar, make, patch and all of the major compression tools.
This means that our package builds can build C/C++ programs, copy files to the
output, and extract downloaded source files by default. You can add other inputs
to this environment if you need to, but for now it works as-is.

[mkderiv]: https://nixos.org/nixpkgs/manual/#sec-using-stdenv

Let's specify the name and version of this package:

```nix
pname = "gruvbox-css";
version = "latest";
```

`pname` stands for "package name". It is combined with the version to create the
resulting package name. In this case it would be `gruvbox-css-latest`.

Let's tell Nix how to build this package:

```nix
src = ./.;
phases = "installPhase";
installPhase = ''
  mkdir -p $out
  cp -rf $src/gruvbox.css $out/gruvbox.css
'';
```

The `src` attribute tells Nix where the source code of the package is stored.
Sometimes this can be a URL to a compressed archive on the internet, sometimes
it can be a git repo, but for now it's the current working directory `./.`.

This is a CSS file, it doesn't make sense to have to build these, so we skip the
build phase and tell Nix to directly install the package to its output folder:

```shell
mkdir -p $out
cp -rf $src/gruvbox.css $out/gruvbox.css
```

This two-liner shell script creates the output directory (usually exposed as
`$out`) and then copies `gruvbox.css` into it. When we run this through Nix
with`nix-build`, we get output that looks something like this: 

```console
$ nix-build ./default.nix
these derivations will be built:
  /nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv
building '/nix/store/c99n4ixraigf4jb0jfjxbkzicd79scpj-gruvbox-css.drv'...
installing
/nix/store/ng5qnhwyrk9zaidjv00arhx787r0412s-gruvbox-css
```

And `/nix/store/ng5qnhwyrk9zaidjv00arhx787r0412s-gruvbox-css` is the output
package. Looking at its contents with `ls`, we see this:

```console
$ ls /nix/store/ng5qnhwyrk9zaidjv00arhx787r0412s-gruvbox-css
gruvbox.css
```

### A More Complicated Package

For a more complicated package, let's look at the [build directions of the
website you are reading right now][sitedefaultnix]:

[sitedefaultnix]: https://github.com/Xe/site/blob/master/site.nix

```nix
{ pkgs ? import (import ./nix/sources.nix).nixpkgs }:
with pkgs;

assert lib.versionAtLeast go.version "1.13";

buildGoPackage rec {
  pname = "christinewebsite";
  version = "latest";
  
  goPackagePath = "christine.website";
  src = ./.;
  goDeps = ./nix/deps.nix;
  allowGoReference = false;

  preBuild = ''
    export CGO_ENABLED=0
    buildFlagsArray+=(-pkgdir "$TMPDIR")
  '';

  postInstall = ''
    cp -rf $src/blog $bin/blog
    cp -rf $src/css $bin/css
    cp -rf $src/gallery $bin/gallery
    cp -rf $src/signalboost.dhall $bin/signalboost.dhall
    cp -rf $src/static $bin/static
    cp -rf $src/talks $bin/talks
    cp -rf $src/templates $bin/templates
  '';
}
```

Breaking it down, we see some similarities to the gruvbox-css package from
above, but there's a few more interesting lines I want to point out:

```nix
{ pkgs ? import (import ./nix/sources.nix).nixpkgs }:
```

My website uses a pinned or fixed version of nixpkgs. This allows my website's
deployment to be stable even if nixpkgs changes something that could cause it to
break.

```nix
with pkgs;
```

[With expressions][nixwith] are one of the more interesting parts of Nix.
Essentially, they let you say "everything in this object should be put into
scope". So if you have an expression that does this:

[nixwith]: https://nixos.org/nix/manual/#idm140737321975440

```nix
let
  foo = {
    ponies = "awesome";
  };
in with foo; "ponies are ${ponies}!"
```

You get the result `"ponies are awesome!"`. I use `with pkgs` here to use things
directly from nixpkgs without having to say `pkgs.` in front of a lot of things.

```nix
assert lib.versionAtLeast go.version "1.13";
```

This line will make the build fail if Nix is using any Go version less than
1.13. I'm pretty sure my website's code could function on older versions of Go,
but the runtime improvements are important to it, so let's fail loudly just in
case.

```nix
buildGoPackage {
  # ...
}
```

[`buildGoPackage`](https://nixos.org/nixpkgs/manual/#ssec-go-legacy) builds a Go
package into a Nix package. It takes in the [Go package path][gopkgpath], list
of dependencies and if the resulting package is allowed to depend on the Go
compiler or not.

[gopkgpath]: https://github.com/golang/go/wiki/GOPATH#directory-layout

It will then compile the Go program (and all of its dependencies) into a binary
and put that in the resulting package. This website is more than just the source
code, it's also got assets like CSS files and the image earlier in the post.
Those files are copied in the `postInstall` phase:

```nix
postInstall = ''
  cp -rf $src/blog $bin/blog
  cp -rf $src/css $bin/css
  cp -rf $src/gallery $bin/gallery
  cp -rf $src/signalboost.dhall $bin/signalboost.dhall
  cp -rf $src/static $bin/static
  cp -rf $src/talks $bin/talks
  cp -rf $src/templates $bin/templates
'';
```

This results in all of the files that my website needs to run existing in the
right places. 

### Other Packages

For more kinds of packages that you can build, see the [Languages and
Frameworks][nixpkgslangsframeworks] chapter of the nixpkgs documentation.

[nixpkgslangsframeworks]: https://nixos.org/nixpkgs/manual/#chap-language-support

If your favorite language isn't shown there, you can make your own build script
and do it more manually. See [here][nixpillscustombuilder] for more information
on how to do that.

[nixpillscustombuilder]: https://nixos.org/nixos/nix-pills/working-derivation.html#idm140737320334640

## `nix-env` And Friends

Building your own packages is nice and all, but what about using packages
defined in nixpkgs? Nix includes a few tools that help you find, install,
upgrade and remove packages as well as `nix-build` to build new ones.

### `nix search`

When looking for a package to install, use `$ nix search name` to see if it's
already packaged. For example, let's look for [graphviz][graphviz], a popular
diagramming software:

[graphviz]: https://graphviz.org/

```console
$ nix search graphviz

* nixos.graphviz (graphviz)
  Graph visualization tools

* nixos.graphviz-nox (graphviz)
  Graph visualization tools

* nixos.graphviz_2_32 (graphviz)
  Graph visualization tools
```

There are several results here! These are different because sometimes you may
want some features of graphviz, but not all of them. For example, a server
installation of graphviz wouldn't need X windows support. 

The first line of the output is the attribute. This is the attribute that the
package is imported to inside nixpkgs. This allows multiple packages in
different contexts to exist in nixpkgs at the same time, for example with python
2 and python 3 versions of a library.

The second line is a description of the package from its metadata section.

The `nix` tool allows you to do a lot more than just this, but for now this is
the most important thing.

### `nix-env -i`

`nix-env` is a rather big tool that does a lot of things (similar to pacman in
Arch Linux), so I'm going to break things down into separate sections.

Let's pick an instance graphviz from before and install it using `nix-env`:

```console
$ nix-env -iA nixos.graphviz
installing 'graphviz-2.42.2'
these paths will be fetched (5.00 MiB download, 13.74 MiB unpacked):
  /nix/store/980jk7qbcfrlnx8jsmdx92q96wsai8mx-gts-0.7.6
  /nix/store/fij1p8f0yjpv35n342ii9pwfahj8rlbb-graphviz-2.42.2
  /nix/store/jy35xihlnb3az0vdksyg9rd2f38q2c01-libdevil-1.7.8
  /nix/store/s895dnwlprwpfp75pzq70qzfdn8mwfzc-lcms-1.19
copying path '/nix/store/980jk7qbcfrlnx8jsmdx92q96wsai8mx-gts-0.7.6' from 'https://cache.nixos.org'...
copying path '/nix/store/s895dnwlprwpfp75pzq70qzfdn8mwfzc-lcms-1.19' from 'https://cache.nixos.org'...
copying path '/nix/store/jy35xihlnb3az0vdksyg9rd2f38q2c01-libdevil-1.7.8' from 'https://cache.nixos.org'...
copying path '/nix/store/fij1p8f0yjpv35n342ii9pwfahj8rlbb-graphviz-2.42.2' from 'https://cache.nixos.org'...
building '/nix/store/r4fqdwpicqjpa97biis1jlxzb4ywi92b-user-environment.drv'...
created 664 symlinks in user environment
```

And now let's see where the `dot` tool from graphviz is installed to:

```console
$ which dot
/home/cadey/.nix-profile/bin/dot

$ readlink /home/cadey/.nix-profile/bin/dot
/nix/store/fij1p8f0yjpv35n342ii9pwfahj8rlbb-graphviz-2.42.2/bin/dot
```

This lets you install tools into the system-level Nix store without affecting
other user's environments, even if they depend on a different version of
graphviz. 

### `nix-env -e`

`nix-env -e` lets you uninstall packages installed with `nix-env -i`. Let's
uninstall graphviz:

```console
$ nix-env -e graphviz
```

Now the `dot` tool will be gone from your shell:

```console
$ which dot
which: no dot in (/run/wrappers/bin:/home/cadey/.nix-profile/bin:/etc/profiles/per-user/cadey/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
```

And it's like graphviz was never installed.

Notice that these package management commands are done at the _user_ level
because they are only affecting the currently logged-in user. This allows users
to install their own editors or other tools without having to get admins
involved.

## Adding up to NixOS

NixOS builds on top of Nix and its command line tools to make an entire Linux
distribution that can be perfectly crafted to your needs. NixOS machines are
configured using a [configuration.nix][confignix] file that contains the
following kinds of settings:

[confignix]: https://nixos.org/nixos/manual/index.html#ch-configuration

- packages installed to the system
- user accounts on the system
- allowed SSH public keys for users on the system
- services activated on the system
- configuration for services on the system
- magic unix flags like the number of allowed file descriptors per process
- what drives to mount where
- network configuration
- ACME certificates

[and so much more](https://nixos.org/nixos/options.html#)

At a high level, machines are configured by setting options like this:

```
# basic-lxc-image.nix
{ config, pkgs, ... }:

{
  networking.hostName = "example-for-blog";
  environment.systemPackages = with pkgs; [ wget vim ];
}
```

This would specify a simple NixOS machine with the hostname `example-for-blog`
and with wget and vim installed. This is nowhere near enough to boot an entire
system, but is good enough for describing the base layout of a basic [LXC][lxc]
image.

[lxc]: https://linuxcontainers.org/lxc/introduction/

For a more complete example of NixOS configurations, see
[here](https://github.com/Xe/nixos-configs/tree/master/hosts) or repositories on
[this handy NixOS wiki page](https://nixos.wiki/wiki/Configuration_Collection).

The main configuration.nix file (usually at `/etc/nixos/configuration.nix`) can also
import other NixOS modules using the `imports` attribute:

```nix
# better-vm.nix
{ config, pkgs, ... }:

{
  imports = [
    ./basic-lxc-image.nix
  ];
  
  networking.hostName = "better-vm";
  services.nginx.enable = true;
}
```

And the `better-vm.nix` file would describe a machine with the hostname
`better-vm` that has wget and vim installed, but is also running nginx with its
default configuration.

Internally, every one of these options will be fed into auto-generated Nix
packages that will describe the system configuration bit by bit.

### `nixos-rebuild`

One of the handy features about Nix is that every package exists in its own part
of the Nix store. This allows you to leave the older versions of a package
laying around so you can roll back to them if you need to. `nixos-rebuild` is
the tool that helps you commit configuration changes to the system as well as
roll them back.

If you want to upgrade your entire system:

```console
$ sudo nixos-rebuild switch --upgrade
```

This tells nixos-rebuild to upgrade the package channels, use those to create a
new base system description, switch the running system to it and start/restart/stop
any services that were added/upgraded/removed during the upgrade. Every time you
rebuild the configuration, you create a new "generation" of configuration that
you can roll back to just as easily:

```console
$ sudo nixos-rebuild switch --rollback
```

### Garbage Collection

As upgrades happen and old generations pile up, this may end up taking up a lot
of unwanted disk (and boot menu) space. To free up this space, you can use
`nix-collect-garbage`:

```console
$ sudo nix-collect-garbage
< cleans up packages not referenced by anything >

$ sudo nix-collect-garbage -d
< deletes old generations and then cleans up packages not referenced by anything >
```

The latter is a fairly powerful command and can wipe out older system states.
Only run this if you are sure you don't want to go back to an older setup.

## How I Use It

Each of these things builds on top of eachother to make the base platform that I
built my desktop environment on. I have the configuration for [my
shell][xefish], [emacs][xemacs], [my window manager][xedwm] and just about [every
program I use on a regular basis][xecommon] defined in their own NixOS modules so I can
pick and choose things for new machines.

[xefish]: https://github.com/Xe/xepkgs/tree/master/modules/fish
[xemacs]: https://github.com/Xe/nixos-configs/tree/master/common/users/cadey/spacemacs
[xedwm]: https://github.com/Xe/xepkgs/tree/master/modules/dwm
[xecommon]: https://github.com/Xe/nixos-configs/tree/master/common

When I want to change part of my config, I edit the files responsible for that
part of the config and then rebuild the system to test it. If things work
properly, I commit those changes and then continue using the system like normal.

This is a little bit more work in the short term, but as a result I get a setup
that is easier to recreate on more machines in the future. It took me a half
hour or so to get the configuration for [zathura][zathura] right, but now I have
[a zathura
module](https://github.com/Xe/nixos-configs/tree/master/common/users/cadey/zathura)
that lets me get exactly the setup I want every time.

[zathura]: https://pwmt.org/projects/zathura/

## TL;DR

Nix and NixOS ruined me. It's hard to go back.