What are nix flakes and why should I care?

Help
1

I’m a crusty nix user who lives under a rock.
I notice the term “nix flakes” popping up in README’s and in other discussions.

Could someone condescend and explain it to me like I am five?

I would most appreciate it and probably become less grumpy.

1 Like
2

In my mind, flakes are essentially a better replacement for channels where the pinning of input revisions are made explicit rather than based on the whims of a nix-channel --update. I mean, there’s a lot more too it than that, but that’s probably the most important piece.

In other words, it allows for your entire nix expression to be reproducible, right down to the revision of nixpkgs. Previously, users could still get different output based on their specific nixpkgs in the NIX_PATH.

With that said, after using them for about 2 years now there are certainly areas for improvement.

2 Likes
3

Another way to say it is: Nix has always been good about being reproducible in regards of a .drv being realized into something useful. However, it’s always had issues with people capturing everything to create a specific derivation. In the old workflow, overlays in the home directory, NIX_PATH, nix-channels, whether it’s the user invoking something or through sudo, and other factors may have contributed to “you got something different on your machine”.

With flakes, everything relevant to building something is expressed in the flake.nix and flake.lock, and you have to explicitly “opt-in” impure behavior so it’s pure by default. So you should have a very high degree of certainty that you will be able to come to the same .drv, and nix has always been good about making a .drv into a reproducible output.

10 Likes
4

So you should have a very high degree of certainty that you will be able to come to the same .drv

If one cares about their nix project being usable by others, this is an important property!

My take; I’ve tried to be “objective” but I know I am biased:

  • Nix projects that do not use flakes, often, fail to evaluate in pure-eval mode. A number of them require their environment to leak in, and thus artificially limit where they can be evaluated/built properly (without forking/patching/etc).

  • Projects that are built using pure-eval (flakes or not) are usable in both pure and impure eval scenarios.

  • Projects that use flakes are currently usable from stable nix via flakes-compat.

  • Flakes is unstable, hasn’t gone through the RFC process correctly/successfully, is still evolving, and has no roadmap.

2 Likes
5

To synthesize the insights from above:

The community has created an experiment, nix flakes, to improve reproducibility guarantees when managing software with nix.

Or a technically worded interpretation: Encode pure semantics by default into how you package and consume nix expressions by way of high-certainty reproducible derivations.

3 Likes