Minimize Download of Dependency Flakes (on demand)

j340m3 · March 23, 2025, 3:12pm

Hi everyone,

long time reader here, never posted something. Until today, I’m stuck.

I have created NixOS-Flake to configure several hosts. Since every Host has a different role, the inputs (Input Flakes) start piling up. Every Host has to download all the inputs, even if they only use a subset.

With a very high autoUpdate interval (hourly), my hosts make so many requests, that I get rate limited from github. (I’m aware that with an github account, the amount of allowed Github-API calls will be more than enough, but thats beside the point)

Since I modularized my repo by roles, I was asking myself, how i have to organize my code, such that when Import a module (role) then and only then will the input be downloaded.

I don’t care for reproducibility that much (I dont write lock files at all) in case that would change your answer.

Feel free to make suggestions, and ask questions if I wasn’t clear. I’m not a native speaker

Thanks

doronbehar · March 23, 2025, 3:33pm

What kind of flake inputs exactly do you have there? Does the automatic update actually updates the inputs? Or does it only check whether there are new commits on the branches you specify in the main flake.nix? I know that these Nix settings are probably relevant:

https://nix.dev/manual/nix/2.24/command-ref/conf-file#conf-tarball-ttl

https://nix.dev/manual/nix/2.24/command-ref/conf-file#conf-narinfo-cache-negative-ttl

https://nix.dev/manual/nix/2.24/command-ref/conf-file#conf-narinfo-cache-positive-ttl

j340m3 · March 23, 2025, 3:40pm

Flake nix:

...
inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable-small";
  
    home-manager.url = "github:nix-community/home-manager/release-24.11";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";

    sops-nix.url = "github:Mic92/sops-nix";
    sops-nix.inputs.nixpkgs.follows = "nixpkgs";

    conduwuit = {
      url = "github:girlbossceo/conduwuit";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    nixos-hardware = {
      url = "github:NixOS/nixos-hardware/master";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
...

Updates:

system.autoUpgrade = {
      enable = true;
      flake = "github:j340m3/nixos";
      #flake = inputs.self.outPath;
      flags = [ 
      # "--update-input" "nixpkgs"
        "--no-write-lock-file"
      ];
      allowReboot = config.allowReboot;
      dates = lib.mkDefault "hourly";
      rebootWindow = {
        lower = "22:00";
        upper = "08:00";
      };
    };

When I manually update the system, I usually run:

nixos-rebuild switch --upgrade --flake github:j340m3/nixos --option tarball-ttl 0 --no-write-lock-file

j340m3 · March 23, 2025, 3:53pm

And I basically want to move the conduwuit input download form flake.nix to /subfolder/role1.nix and only when role1.nix is imported, then nix should download the dependency (if there is a newer version)

waffle8946 · March 23, 2025, 4:19pm

Remove --upgrade, it does nothing with flakes.

I’d also recommend you not use this, this will essentially disable your user’s flake cache, and will cause you to hit the rate-limit sooner.

Anyway, what you want is not possible with flake inputs currently.

There’s some speculative PRs to improve the situation. Though even then, all inputs must be located in the flake.nix, you can’t split them up into multiple files.

github.com/NixOS/nix

Make `nix flake metadata|update|lock` lazy

NixOS:master ← DeterminateSystems:lazy-flake-commands

opened 09:45PM - 06 Feb 25 UTC

edolstra

+94 -31

## Motivation These don't need to evaluate anything (except for the flake metadata in `flake.nix`) so we can make these commands operate on lazy trees (i.e. without having to copy the inputs to the store) without risk of any semantic change in the evaluator. However, as a result, `nix flake metadata` now no longer prints the store path, which is a breaking change (but unavoidable if we want lazy trees). So calls like `nix flake metadata --json | jq .path` should be replaced by `nix flake prefetch --json | jq .storePath`. Depends on #12421. TODO: add release note. ## Context --- Add :+1: to [pull requests you find important](https://github.com/NixOS/nix/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc). The Nix maintainer team uses a [GitHub project board](https://github.com/orgs/NixOS/projects/19) to [schedule and track reviews](https://github.com/NixOS/nix/tree/master/maintainers#project-board-protocol).

github.com/NixOS/nix

Lazy trees

NixOS:master ← edolstra:lazy-trees

opened 07:10PM - 12 May 22 UTC

edolstra

+1363 -364

# Features * Flake inputs are now only copied to the Nix store if that's act…ually needed (fixing #3121). That is, an operation like `nix build nixpkgs#hello` no longer copies the `nixpkgs` flake to the Nix store. Only an expression like `src = ./.` or `nix.registry.nixpkgs.flake = nixpkgs;` will cause an entire flake to be copied. * `fetchTree` can now apply patches to a tree, e.g. `fetchTree { ...; patches = [ ./foo.patch ./bar.patch ]; }` (#3920). Patches are applied in memory, so this doesn't require the entire tree to be materialized to disk. * The `github` fetcher now fetches zip archives instead of tarballs, and does not unpack them to disk. Depending on the filesystem, this can save a lot of disk space. (E.g. on ext4 with a 4 KiB block size, an unpacked Nixpkgs tree takes 252 MiB, whereas the zip archive takes 43 MiB. # Design The evaluator no longer accesses the filesystem directly. Instead, it uses a virtual filesystem abstraction called `InputAccessor`, which has FS operations like `readFile()` . You can get the `InputAccessor` for an `Input` by calling `Input::lazyFetch()`, which unlike `Input::fetch()` does not (necessarily) copy the input to the Nix store. The following `InputAccessor`s currently exist: * `FSInputAccessor`: This directly accesses the host filesystem, optionally rooted at some prefix. This is used for both non-flake evaluation (e.g. `nix-build ./foo.nix`), for `path://` flakes, and for (dirty or clean) Git working directories (`git+file://`). It optionally takes a set of allowed paths, which is used by the Git input type to ensure that you can't access untracked files. * `MemoryInputAccessor`: An in-memory filesystem, used to provide `<nix/fetchurl.nix>`. * `ZipInputAccessor`: An accessor that reads directly from a zipfile, using libzip. Used by the `github` fetcher. * `PatchingInputAccessor`: An adaptor that wraps another accessor whose `readFile()` applies a patch to the file returned by the underlying accessor. Paths are represented inside the evaluator using the `SourcePath` type, which is a tuple of an `InputAccessor` and a path relative to the root of the input. So the `SourcePath` `{input->lazyFetch(), "/flake.nix"}` represents the file `flake.nix` inside some input. # Incompatible changes The `outPath` attribute returned by `fetchTree` et al. is no longer a store path but a path (i.e. a `SourcePath`). This can cause some breakage, e.g. in NixOS, setting ``` nix.registry.nixpkgs.flake = nixpkgs; ``` causes the error `A definition for option 'nix.registry.nixpkgs.to.path' is not of type 'string or signed integer or boolean or package'`. Instead you have to write: ``` nix.registry.nixpkgs.flake = "${nixpkgs}"; ``` to force the argument to be a store path. # To do - [x] Fix many test failures. - [x] Fix showing source code in error messages. Currently the error formatter doesn't know anything about `SourcePath`s. - [x] Give a helpful message when trying to use untracked files in a git repo (#4507). - [x] Fix the evaluation cache. - [x] Fix flake locking. - [x] Get rid of the `narHash` attribute in `flake.lock`? Computing it is expensive since it requires reading the entire source tree. However, we need it to be able to substitute flake inputs, but maybe we don't care about that. - [x] What to do with `path://` inputs? They're only locked by `narHash`, so if we don't have `narHash`, we can't lock `path://` inputs. - [x] Fix/improve subflake handling. - [ ] Update release notes / docs. # Context - Closes #3121 - Closes #3920 - Closes #5973

doronbehar · March 23, 2025, 4:22pm

OK nothing very special I see there - the inputs are not updated frequently enough to justify such an intensive hourly automatic update. Currently Hydra’s web interface gives me 504 timeout, but in principal here you should be able see the frequency in which the channel you are using is updated. Other channels’ update frequency can be inferred from here. IIRC that for nixos-unstable-small it is less then twice a day.

I believe that Nixpkgs is the most frequently updated flake input you have there, and hence running your update 4 times a day should be enough to guarantee your are up to date all the time. See Nyquist–Shannon sampling theorem - Wikipedia .

I think you might be able to hack something with builtins.getFlake, but the problem is you won’t get the benefits of committing flake.lock and tracking the commit hashes you are actually using in each system evaluation.

Long story short: No need to update flake inputs hourly :).

waffle8946 · March 23, 2025, 4:23pm

Also, why are you using flakes at all if you don’t care about lockfiles? The entire point of flakes is to provide pure eval which implies a lockfile spec.

j340m3 · March 23, 2025, 5:04pm

Have a nerd cookie for citing Nyquist-Shannon (But wouln’t that just ensure that I would get
every state change? I would still have to wait an average of 3 hours until I would get my tasty updates )

What is the time interval string for every 6 hours? I once tried a few strings but then got frustrated and went with hourly.

Is there a way to set this option granulary for each input? When I push a change to my github repo, I would have to wait for a long while until the nixos-rebuild switch-command would get the newer commit.

You’re absolutly right, it’s a bit nonsensical. Here some explanations:

I’m still learning nix, I didn’t know better. Maybe technical debt?
Lots of code snippets and tutorials use flakes and it was harder for me to stick to a non-flake version.
I (mis-)use NixOS as kind of a reverse Ansible. I liked the idea of reproducibility, but at one point, logging into every host to update the lock files felt tedious. So I changed parts of my setup so that I only need to touch it, when the syntax of packages changes (e.g hardware.alsamixer → services.alsamixer…).

j340m3 · March 23, 2025, 5:10pm

And nixos did complain, that it couldn’t write a lock file for the flake…

doronbehar · March 23, 2025, 5:36pm

As the docs of this dates option states, the syntax is explained (pretty good IMO) in the manpage systemd.time(7). ~~I think that every 6 hours can be set via simply dates = "6h";.~~

Have an obsession cookie for asking that . And seriously: If you are really that impatient - setup a GitHub API key.

j340m3 · March 23, 2025, 6:04pm

I tried it with “6h”, and “6hours”, which would also be in spec. Nixos begs to differ:

restarting the following units: nixos-upgrade.timer
Failed to restart nixos-upgrade.timer: Unit nixos-upgrade.timer has a bad unit file setting.
warning: error(s) occurred while switching to the new configuration

And about the updates, I was just nitpicking

j340m3 · April 1, 2025, 4:19pm

Every 6 h = *-*-* 0/6:00:00 for anyone that finds this