Nix: Why my dotfiles home-manager flake is installing notmuch?

Jul 16, 2022

I use home-manager to manage my dotfiles while using Debian/Ubuntu as host OS.

Most of my packages use stable channel but when needed, I opt in to stay on top of unstable, pkgs.latest in my case.

I’ve noticed that very often, far too often, even when not much has changed, I’m stuck waiting for something like 5 minutes, recompiling notmuch.

Notmuch is a mail indexer. Essentially, is a very thin front end on top of xapian.

I went into my dotfiles repo and ran ripgrep

$ rg notmuch | wc -l
0

Well… it looks like I don’t have it installed? I also don’t have any mailbox locally nor email related dependencies.

Let’s use why-depends to get a better picture.

$ home-manager build --flake "$(pwd)"
$ nix why-depends  ./result nixpkgs#notmuch
error: argument 'flake:nixpkgs#notmuch' should evaluate to one store path

Uhh, that’s useless. I’ve got no idea what to do with this error message. I know that “./result” should work, but why there’s an error about notmuch? Another try:

$ nix why-depends --derivation ./result nixpkgs#notmuch
'/nix/store/1galbnf945r6h1xmx4dhzgmqybzvaddh-home-manager-generation.drv' does not depend on '/nix/store/x9j43hpzkgsinskp0gjidhqh4z3v0rsr-notmuch-0.36.drv'

Ok, we’re getting somewhere. As I had told at the beginning, I’m using mix of unstable and stable dependencies. Probably this is the case where I’m using the stable version!

It will be safer to simply to refer to the attributes from the flake itself.

My home-manager configuration is in format “user@hostname”, and home-manager exposes pkgs, so we can use that.

$ nix why-depends --derivation ./result .#homeConfigurations."$(whoami)@$(hostname)".pkgs.notmuch
/nix/store/1galbnf945r6h1xmx4dhzgmqybzvaddh-home-manager-generation.drv
└───/nix/store/s4msd0hdl8vvq9xl2icbgbyb8mrby52s-home-manager-path.drv
    └───/nix/store/vcn4yjrhyzjxcfzys9dc4h689pbf3b4m-i3status-rust-0.21.10.drv
        └───/nix/store/6ndarxzk8pzlsldgdfc0xwib4f1m1pvz-notmuch-0.35.drv

Yay! We’ve got our result, it’s i3status-rust! I’d have never expected it to pull in notmuch, let me quickly check what’s going on…

It’s optional dependency, but pulled in always on i3status-rust installation due to this buildInput.

That’s it! I’ll defer making it optional in nixpkgs, and/or my own configuration as a future exercise.


In case you have any comments or questions - feel free to contact me at email.