follows behavior for flakes used as inputs

[mkenigs]

Follows seems to break when a flake that has follows is used as an input for another flake. For example for a circular dependency flakeB<->flakeC, if flakeA inputs flakeB it causes a circular import error. If A->B->C and A->D->C2 but B follows D/C, the follows works, but if another flake inputs A, B no longer follows D/C.

The RFC says follows should be a path from the root flake, but it looks like sometimes the path is actually treated as relative

nix/src/libexpr/flake/flake.cc

Line 366 in 5f64655

/* Otherwise, it's relative to the current flake. */

Not sure what the intended behavior is, but it seems kind of brittle to require a flake to know the path it is being input along, and it might be better to always treat a follows as relative to the flake where it is defined.

[stale]

I marked this as stale due to inactivity. → More info

[mkenigs]

The implementation of follows and overrides are related, so I think changing follows behavior depends on #4004

[tejing1]

I also just encountered this bug. I have, in the inputs section of my main nixos config flake:

inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-21.05";
inputs.home-manager.url = "github:nix-community/home-manager/release-21.05";
inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs";

then I made (programatically as part of my nixos system generation) a small flake which I registered as 'pkgs' with nothing but the following flake.nix: (the nix store path points to the current rev of my main nixos config flake)

{
  inputs.config.url = "path:/nix/store/174i3c4d8v3zx7j2hijsmjfln05c50xf-source";
  outputs = { self, config }: {
    legacyPackages."x86_64-linux" = config.nixosConfigurations."tejingdesk".pkgs;
  };
}

the idea was to allow commands like nix shell pkgs#foo to access overlays and other nixpkgs configuration specified in my system config, but instead I get this:

error: input 'config/home-manager/nixpkgs' follows a non-existent input 'nixpkgs'

It seems that "follows" attributes are being interpreted from the pkgs flake, rather than the flake they are written in, which in essence means they can't be used in any flake that might be an input to another flake.

I would expect that the follows line I have written would have the same effect as putting

inputs.config.inputs.home-manager.inputs.nixpkgs.follows = "config/nixpkgs";

in the pkgs flake, but instead it seems to be equivalent to putting

inputs.config.inputs.home-manager.inputs.nixpkgs.follows = "nixpkgs";

there.

[tejing1]

PR #4641 seems to fix this issue?

[rocky-fuchsian-frog]

I just wanted to add in a similar issue I'm having in the hopes that maybe someone can help me. So I have a flake:

{
  description = "The www development shell";
  inputs.flake-utils.url = "github:numtide/flake-utils";
  inputs.nixpkgs-fmt.url = "github:nix-community/nixpkgs-fmt";
  outputs = { self, nixpkgs, flake-utils, nixpkgs-fmt }:
    flake-utils.lib.eachDefaultSystem
      (system:
        let pkgs = nixpkgs.legacyPackages.${system}; in
        {
          devShell = pkgs.mkShell {
            buildInputs = [
              nixpkgs-fmt
            ];
          };
        }
      );
}

which fails on nix develop with:

error: input 'nixpkgs-fmt/fenix/naersk' follows a non-existent input 'naersk'

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/possible-nix-flake-hierarchical-lookup-bug/14057/2

[mikepurvis]

I recently adopted follows in my hierarchical flake setup and hit this as well (with Nix 2.6.1). I have:

A -> B -> C -> D -> nixpkgs

C also has nixpkgs as an input, and has a follows declaration so that D should use C's nixpkgs. All this works fine when B is used directly, but once A uses B as an input, I get eg:

error: input 'B/C/D/nixpkgs' follows a non-existent input 'C/nixpkgs'

When going "up a level", it should have been looking for B/C/nixpkgs rather than C/nixpkgs.

EDIT: I can confirm that this issue still exists in Nix 2.8.0pre20220413_0e58aff.

[shadowrylander]

Also happening on the latest master:

nix (Nix) 2.10.0pre20220706_f6316b4

[mikepurvis]

From my trivial reproduction, this appears to now be fixed in nix (Nix) 2.12.0pre20221005_ac0fb38, likely due to #6983

Thanks @edolstra!

[cfhammill]

I'm still seeing this issue on nix (Nix) 2.12.0

[shroomist]

,I'm in the same boat, observing this behavior on nix (Nix) 2.12.0

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-flake-to-aggregate-and-concurrently-update-some-dependencies/10774/10

[sellout]

I had an issue like this, not sure if exactly the same case, but it was solved for me some time between Nix 2.13.5 and 2.18.4.