Nix flake update to latest version 7 days ago

With wave after wave of compromised packages all over the place, is there a way to update a flake but enforce a 7 day lag ?

I guess I could run nix flake update, build only and wait 7 days before switching but that’s quite painful as It means I can’t change or test anything within the quarantine period.

Instead I would like the `nix flake udpate` command to update to the hash(es) of now()-7d.

I hope my question is clear enough

You could query the history of nixos-unstable at Commits · NixOS/nixpkgs · GitHub, pick a commit from there, and just set inputs.nixpkgs.url = "github:nixos/nixpkgs/<myhash>"; in your flake. You could write a script to automate this I suppose.

I tried this, this seems a step in the right direction, though it doesn’t work entirely yet: gh api repos/NixOS/nixpkgs/commits?sha=nixos-unstable --cache 1h --paginate -q "map(select((.commit.committer.date | fromdate) < $(date --date='last week' -u '+%s')))[0].sha"

One thing to note is that the link @dtomvan gave for nixos-unstable history includes every master commit that’s at least as old as the current nixos-unstable commit, including lots of commits that nixos-unstable never actually pointed to. So you could easily end up on a commit for which the corresponding jobset failed, and then you get build failures for your config.

If you want to only consider commits that nixos-unstable has actually pointed to previously, you could use a tool like npc (disclaimer: I’m the author of this tool). The one thing to consider there, though, is that npc still only tells you when each commit was created, and not when the channel updated to point to that commit. Channels lag behind master because they only update periodically, but even if they updated continuously, they’d still lag because they never actually update to the current latest master commit.

1 Like

You could continuously update and store flake.lock in a separate branch and checkout a 7 day old flake.lock when you want to switch your OS.

Wait, how does it even do that? How can you, without continuously tracking pushes, detect which commits were the tip of the branch at some point in time?

You can’t do it for an arbitrary GitHub repo, as far as I know. For Nixpkgs specifically, that information is stored in an S3 bucket, which you can browse here: https://releases.nixos.org/

I like this idea, I think I’ll look into scripting this

Most package managers I know support this kind of features, I’m a bit surprised it’s not native in nix.Maybe an idea for an improvement :smiley:

As the replies above mentioned, querying the GH repo might not give you a revision that matches a channel release and thus lead to rebuilds.

But you can find a history of channel bumps from GitHub - wamserma/flake-programs-sqlite: A simple flake to automagically specify programs.sqlite for command-not-found. · GitHub

Once cloned, you can find the last channel bump before a given date by

git checkout `git rev-list -n 1 --first-parent --before="2009-07-27 13:37" master`

then just pick the desired URL to nixexprs.tar.xz from latest.json and override your flake input with that URL.