Snowfall Lib v2 with per system flake.lock

Help
1

Hey everyone, so I’m using Snowfall Lib v2 for having a relatively structured approach to managing my nix configs.

I was wondering if there was a way to have a flake.lock file per host. The reason I ask this is because, running nix flake update will update the flakes for all hosts. Under normal circumstances this is not a problem. But recently I ran into an issue where nixos-rebuild switch worked successfully on host 1, but not on host 2 after the nix flake update. Host 2 had the cloud-init module which was breaking for some reason. Anyways long story short if I could manage 2 flake.lock files per host, this wouldn’t have been a problem, since after the failed updated on host 2. I would 've just reverted the flake.lock file for host 2, thereby having a perfectly reproducible config.

Please do suggest any other ways of solving the problem as well. The simplest I thought was to manage 2 flake.locks, but if there are more, do suggest.

2
  1. You’re better off by investigating the build failure.
  2. Me personally, I do not update the flake.lock file that’s tracked by git. Instead, I run a nix flake update on each machine so I can roll it back to a previous version manually.
2 Likes
3
  1. Investigating the build failure is a given. However in the meantime, I don’t want my system to be in an inconsistent state from my git repo.
  2. Commiting flake.lock is also a very standard practice I feel. Examples: package-json.lock (for npm), poetry.lock (for python) projects. Its makes things a notch closer to reproducible. Also the whole point of using flakes was to maintain package versions for easier reverts. Running nix flake update on each machine is good, but that limits me to not push remote updates via using --target-host and --build-host. I update my remote systems from my local workstation, thereby always having my git repo being the single source of truth.
4

You could temporary switch to a separate git branch on the host that fails to build.

Merge changes from the main branch except for flake.lock.

Switch to your main branch to test the frequently updated flake.lock, and back to the temporary branch for as long as that fails.

1 Like
5

The names of any flake inputs are quite arbitrary.
You can name an input, for example, nixpkgs-host1, i.e.

inputs.nixpkgs-host1.url = "github:NixOS/nixpkgs/nixpkgs-unstable";

And then only update the nixpkgs-host1 input when you’re ready to update that, leaving the -host2, -host3, etc. alone.
I’d personally find this extra work, but I guess either way you’ll end up doing work here.

1 Like