A common theme among the people who fall in love with Nix (or its cousin NixOS) is that they want it to manage everything for them. Finding out the limits of that capability and where it breaks down is part of each’s journey.
An obvious enough limit to Nix’s reach is secret management. It can easily handle public keys, SSH or cryptographic ones, but the private keys cannot be managed by its store as it is readable by all.
The promise of Nix is that we will never break our system by updating
it. We can always roll back to a previous working version, once we have
a working version at all. This is in contrast to, say, every other Linux
distribution. I have borked Ubuntu, Arch, Fedora and others during system
updates. Often the safest way to update the system is to back up
and reinstall the OS.
From somewhere comes the idea that a user on a Linux system should be able to install their own programs and manage their own system services. (See Chris Wellons for where you can run with this idea to if your sysadmin gives you a C compiler.) This seems odd from a historical perspective. In a true multi-user system, the system administrators normally do not want users to be able to install arbitrary software or run services. On a modern "multi"-user system, where there is a only single user, avoiding system packages and services seems like some kind of theater.
Yet we do it anyway. An argument I sometimes make to myself is that this is a cleaner separation between what I need the system to do versus what I do on it. I may want to be able to run traceroute as root, but I don’t care about root being able to run the Go compiler.
NixOS has facilities to enforce this separation. It happily creates users and their home directories, and can fill in some of the bits that go there, like public SSH keys. It can install packages for specific users, and allow them to define systemd services. It will not manage the configuration of specific user packages (like dotfiles) without some coercing. One can presumably create custom derivations of, say, ZSH with all the configuration one wants, but who has the time?
Home manager wants to fill this gap and bring the power of Nix to user environment and configuration management. It lets individual users say what packages they want installed; what services they want run; and what configuration files should go where. On the surface it seems like something I should love, but after using it for a month I wrote it out of my system and now use plain NixOS.
I used Home manager for three things:
Installing packages for my user.
Scheduling services for my user.
Installing configuration files for my software.
The first one was never a big attraction. Home manager lets us define
a list of packages in
home.packages of packages to install. If we
control the system configuration, we can acheive the same by defining
those packages in
If a user controls the system configuration (directly or through
a sysadmin), they can also define their own user services via
systemd.user. Home manager’s selling point is that it comes with a
large list of already defined services that we can enable with a boolean
flag, instead of having to write our own service configuration. This is
admittedly nice. In the end, I found that learning the idiosyncrazies
of each home manager service definition was a less useful use of my time
than learning how to define NixOS systemd services once and for all. The
latter is after all where the former end up.
As a long-time sufferer of dotfile management, I had high hopes for the third point. And indeed, home manager will manage dotfiles just fine. It can do this in two modes: it can generate a config file from various options we fill out if someone has written a home manager module for the program we’re trying to configure, or it can plomp a file on the system verbatim from a source. I used the latter, as I didn’t feel like learning a configuration language to be able to partially configure program dotfiles was a good idea.
This works well, until we want to change anything in a dotfile. This
experiment with home manager coincided with a regular low point in my life
in which I try to use emacs. This comes with quite a lot of .emacs changes
as I use Lisp for the only thing it’s ever been good for; configuring
a text editor in the most complicated way imaginable. Now, the dotfiles
that home manager (or Nix) puts on our systems are read-only, so every
change would involve changing the source file and running
switch. This seems like unnecessarily many steps, especially after I
saw this brilliant Hacker news
comment, which after a week of use is a much better solution for this problem.
All in all home manager is nice software. I can see it being useful for people who either don’t control the system they run on but want to use Nix in user mode to run their corner of it, or for those Nix users who gamers (a well-adjusted group of humans if there ever was one) would call "filthy casuals", that is, people who just want things to work and don’t care very much about learning how to write enough Nix to make that happen.
I’m not included in those groups, as I run this system and explicitly want to learn to use Nix in anger so I can try and fail to convince people to run it in production at work. Home manager is fine software and if it makes you happy, then please use it.