Is using recursive `.follows` supposed to make nix update the version of the input used by its parent?

Help
1

Hey, I’m trying to untangle my flake.lock in a project using crate2nix - that repo has a very creative use of flakes, and doesn’t seem to update its inputs often, which makes this somewhat tricky.

My inputs currently look like this:

# flake.nix
{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";
    crate2nix = {
      url = "github:nix-community/crate2nix";
      inputs = {
        nixpkgs.follows = "nixpkgs";
        cachix.inputs = {
          nixpkgs.follows = "nixpkgs";
          git-hooks.inputs.gitignore.follows = "crate2nix/pre-commit-hooks/gitignore";
        };
        pre-commit-hooks.inputs.flake-utils.follows = "crate2nix/devshell/flake-utils";

        # Yes, they do this insanity:
        # https://github.com/nix-community/crate2nix/issues/371
        crate2nix_stable.follows = "crate2nix";
      };
    };
  };
}

This seems to produce the most minimal flake.lock possible, which is nice, because this wastes less time updating and downloading repositories (and hammers the GitHub API less). It’s annoying to have to untangle a dependency’s inputs, especially since most of those recursive inputs are purely dev related and will never do anything on my end (subflakes, anyone?), but eh, I digress.

I get these warnings though:

warning: input 'crate2nix/cachix' has an override for a non-existent input 'pre-commit-hooks'
warning: input 'crate2nix/pre-commit-hooks' has an override for a non-existent input 'flake-utils'
warning: input 'crate2nix/pre-commit-hooks' has an override for a non-existent input 'nixpkgs-stab

The only one that made any sense to me was the flake-utils override, however that input clearly exists because removing that line adds a second flake-utils to flake.lock.

It took me a while of enabling and disabling that override to spot this:

• Updated input 'crate2nix/pre-commit-hooks':
    'github:cachix/pre-commit-hooks.nix/e35aed5fda3cc79f88ed7f1795021e559582093a' (2024-04-02)
  → 'github:cachix/pre-commit-hooks.nix/7275fa67fbbb75891c16d9dee7d88e58aea2d761' (2025-11-16)

And indeed, the pre-commit-hooks repo removed the input between those commits, while crate2nix has that input locked to the older commit.

This implies that setting a .follows on an input recursively makes nix ignore what commit its parent flake locks it to. Is this intended behavior?

2

I don’t see that behavior or the mentioned warnings (lix 2.93). What nix version do you have? I do recall some bugs around recursive follows like nix flake update and nix flake lock disagree on how to handle nested follows · Issue #5728 · NixOS/nix · GitHub - and of course lix has had their own bugs like https://git.lix.systems/lix-project/lix/issues/465 and https://git.lix.systems/lix-project/lix/issues/460

3

Yep, appears to be a lix bug; I am on:

nix (Lix, like Nix) 2.91.3

Bumping to 92 and running nix flake update fixed the flake.lock, and now the warnings are gone on 91 as well.

Edit: … Except running any kind of command on 91 breaks the careful balance again :smiley: Guess I’ll bump my lix version.

1 Like
4

Yeah makes sense, the fix flake: don't refetch unmodified inputs by recursive follows · 040e783232 - lix-project/lix - Lix Systems for the second lix issue is included from 2.92 onwards. I think that’s related to this issue.

1 Like