To flake or not to flake

colemickens · November 16, 2020, 10:03pm

In my opinion, as a Nix user, Flakes are safe to adopt from a functionality standpoint. They are basically just some syntax: https://github.com/colemickens/nixos-flake-example (a demo showing flakes and regular nix-build building the same store path from a configuration). Also, you can achieve almost the same functionality with hand-written fetchTarball calls, or by using niv.

However, there are some things flakes addresses that aren’t easily addressed without flakes. Consider, troubleshooting a nix-env -iA command failing for a one-off user, with Nix today…

wait, what is your NIX_PATH set to?
wait, what do you have in ~/.config/nixpkgs or overlays/? or wait, what about overlays.nix?
oh hey there’s ~/.config/nix too, but it probably doesn’t matter, hopefully?
what does nix-channel --list say?
Oh wait, you’re using nixos-rebuild, aka you’re probably actually using sudo nixos-rebuild… so you have to know to actually reconfigure your channels with sudo nix-channel
oh wait, also don’t forget sudo nix-channel cmds won’t affect nix-env commands.
oh and of course watch the sudo/sudo-less for (sudo) nix-channel --update too, you probably need both!

These things are not issue with flakes. Flakes bring locally, explicitly defined dependencies to Nix projects, and enable pure evaluation by default. That alone makes it easy for me to adopt flakes.

nix build github:colemickens/nixcfg/$REV#toplevel.slynux

will build the exact same store path for anyone regardless of their local nix/nixpkgs config. It feels like how nix is meant to work.

However, there are still some UX issues with flakes that prevent me from recommending it unreservedly:

nix: flakes: allow overriding flake inputs in bulk with extra nix file #4193 (minor, but related to the next one)
flakes: nix build --override-input should NOT update flake.lock #3779 (affects me regularly)
Adding package to devShell causes error: stack overflow (possible infinite recursion) #3821 (majorly painful, I flat out can’t use nix develop for most of my environments because of this bug)
nixFlakes: can’t figure out nix-instantiate equivalent #3908 the attempts to hide derivations and the --derivation flag seems like a misfeature to me, but I think there’s a bigger picture that I’m not clued into. It has caused confusion to a number of people (source: my issue about evaling to get the raw derivation that has reactions, having helped other people who thought they had to give up on flakes.)
(minor) it’s annoying to have to use nix-shell so aggressively to deal with small behavioral changes in the nix CLI (nix copy building derivations for example), or to have --experimental-features at all, etc, etc.

Retrofitting flakes onto a repo isn’t hard in my experience. Add a flake.nix, plumb through outputs from default.nix that you want exposed, replace unversioned fetchTarball calls with flake inputs, remove uses of currentSystem.

As for “propagating overlaid nixpkgs”, I just expose it as an extra output attribute in my nixcfg repo. nixcfg#packages is just my config-local packages, but nixcfg#pkgs is a full nixpkgs with my overlays applied so that I can run nix profile install nixcfg#someOverlayPkg and have it work.