# nixos-config is the directory containing flake.nix
sudo nixos-rebuild switch --flake ./nixos-config
I was expecting no build at all because I thought I changed nothing from the system point of view. But it was not the case: it was starting to download a lot of stuff.
They are probably pointing to different revisions of nixos-24.05. Please compare nix-instantiate --eval -E '(import <nixos> {}).lib.version' and nix eval --expr "let f = builtins.getFlake (toString ./nixos-config); in f.inputs.nixpkgs.lib.version" --impure
To expand, nixos-24.05 is a branch, not an immutable tag - it receives changes all the time. Neither channels nor your flake inputs update automatically - you need to do something like nix-channel --update or nix flake update for your channel / flake input to get updated to the latest commit of the branch.
Disclaimer: possibly not a 100% accurate answer on all details.
When a large amount of data is downloaded on a stable channel (also on unstable) that sounds very likely that it includes a staging merge (so staging-next* to the respective building channel), which has caused a mass-rebuild.
That will result (by the nature how nix treats dependencies) in rebuilding a lot of packages [building could mean here that hydra does build them for the users and the user just downloads the content from hydra).
The “scan” if something is available just downloads the info files and should not accumulate to gigabytes. But if it needs to check for the info files, it will also have to download the resulting archive, otherwise the content would have sit in the local cache. The “scan” just checks if it needs to build it locally or can download it from a cache.
Channels and a flake input are some totally different way of managing your (systems) dependencies.
You can set up a system flake to also update the channels configuration to not have those looking at different revisions, but beside that you have to manage them separately (so when your system uses channels but you have project flakes)
Also a project flake will likely point to a different nixpkgs revision than your system flake unless to take care that they are the same (e.G by manually updating them together, or using follows beside the input when being used in the system flake).
For standalone project flakes I am not aware to autofollow system flakes, and also don’t see why they should do that.
You can kinda do that by using the nix registry, which these days is set up to track your system flakes’ nixpkgs by default.
Which incidentally is another small difference, when using flakes NixOS will automatically set up some flake integration options, like this one. That won’t by itself result in a big rebuild, of course, but there will be some changes even if the commits match.
Does the flake registry also lock on specific revs? i just was aware that its linking to aliases.
If it locks to revs i should take a deeper look at them as i have quite some small project files which annoy me to update them all separatly
If you use the NixOS flake integration, it aliases to a path. See:
tlater ~ $ nix registry list
system flake:nixpkgs path:/nix/store/5z81la6av4j0ckp0w1949lxiwjyyykks-source
That said, if you actually use that reference in a flake, it locks to the path at the time the lockfile is created, because the lockfile obviously is the ultimate source of truth, so actually updating still requires an extra step.
I’m still not really sure how I feel about using the nix registry for this, but it is convenient to know that nix flake update in third repositories doesn’t duplicate nixpkges all over the place, at least.