Regression: Nix flake ignores local registry

[tobiasBora]

Describe the bug

I used to be able to specify in a flake nixpkgs.url = "flake:nixpkgs"; to mean that I should follow the system registry nixpkgs. This was really practical for small local projects, or when deploying a flake to multiple machines where the PATH to a flake differs between machines.

Sadly it seems like this is buggy now. This actually tries to fetch the latest version on github instead of using my local version.

Steps To Reproduce

Create flake.nix with

{
  description = "A very basic flake";

  inputs = {
    flake-parts.url = "github:hercules-ci/flake-parts";
    nixpkgs.url = "github:nixos/nixpkgs/c97c47f2bac4fa59e2cbdeba289686ae615f8ed4";
  };
  
  outputs = { flake-parts, ... } @ inputs: flake-parts.lib.mkFlake { inherit inputs; } {
    perSystem = { config, self', inputs', pkgs, system, ... }: {
      devShells.default = pkgs.mkShell {
        nativeBuildInputs = with pkgs; [
          nodejs_22
          playwright-driver.browsers
        ];

        shellHook = ''
          export PLAYWRIGHT_BROWSERS_PATH=${pkgs.playwright-driver.browsers}
          export PLAYWRIGHT_SKIP_VALIDATE_HOST_REQUIREMENTS=true;
          export PLAYWRIGHT_NODEJS_PATH=${pkgs.nodejs_22}/bin/node
          playwright_chromium_revision="$(${pkgs.jq}/bin/jq --raw-output '.browsers[] | select(.name == "chromium").revision' ${pkgs.playwright-driver}/browsers.json)"
          export PLAYWRIGHT_LAUNCH_OPTIONS_EXECUTABLE_PATH=${pkgs.playwright-driver.browsers}/chromium-$playwright_chromium_revision/chrome-linux/chrome
          echo "Using $PLAYWRIGHT_LAUNCH_OPTIONS_EXECUTABLE_PATH"
        '';
      };
    };
    # Declared systems that your flake supports. These will be enumerated in perSystem
    systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
  };
}

and run nix develop

Expected behavior

It should use my machine nixpkgs version while I see it trying to download a very recent version.

Metadata

❯ nix-env --version
nix-env (Nix) 2.31.2

Additional context

See also discussion in https://discourse.nixos.org/t/flake-does-not-follow-local-nixpkgs-anymore-even-with-flake-nixpkgs/76052

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[xokdvium]

Intentional change since 2.26 #13156

[tobiasBora]

Thanks for pointing to the discussion. Ok, I think I understand the motivation a bit better, but I think we should find a solution to fix the issue motivating the change + the issues I'm raising. My understanding is that before, when a user were using a repo with a non-global registry like flake:nixpkgs, this would write in the lock file something like (copy/pasted from an old project of mine using this feature):

    "nixpkgs": {
      "locked": {
        "lastModified": 1709479366,
        "narHash": "sha256-n6F0n8UV6lnTZbYPl1A9q1BS0p4hduAv1mGAP17CVd0=",
        "path": "/nix/store/bjvqq8c79dbi59g7xzcc6lhl0f19m3d7-source",
        "rev": "b8697e57f10292a6165a20f03d2f42920dfaf973",
        "type": "path"
      },
      "original": {
        "id": "nixpkgs",
        "type": "indirect"
      }
    },

i.e. the path to the repo is written and points directly to the nix store, and this path may not be available on a different computer I guess, breaking compatibility when another user is using it since they may not have this path in their store.

However, I do think that registry can still be useful in some cases:

• modularity & composablity: registries are for me a really clean way to abstractly refer to a flake without hardcoding in the flake how to fetch it. I use it extensively for instance in a project where a flake A was a local flake in my home folder (basically a nixos configuration to setup a specific web service), and then I could call flake A from other flakes (flake B, flake C)… without worrying about the path to reach flake A. This way, if I change the location of flake A, I just need to update my registry and all other flakes will just work as before. This is also really helpful when deploying to a different machine (I was relying on it to deploy to a server but a different user machines, possibly the one of a collaborator, would also apply) since paths to the repository may differ.
• this also allows me to easily specify "this flake should use the same nixpkgs as my system". This way I get reproducibility (rev is written in the flake.lock) and I don't have 20x different version of nixpkgs on my machine (not really space/bandwidth efficient).

I'm sure we can find a solution that fixes the original issue while allowing the two use cases I'm mentioning here, simply by saying to flake that if they can't find the path in nixpkgs.locked.path, then they should try to recreate it from the nixpkgs.original path using the revision in nixpkgs.locked.rev. Since my understanding is that this path is always in the nix store, this should always be possible I guess. I'm even curious to understand why this is not already the case.

Also pinging @edolstra since you are the author of this change.

[nixos-discourse]

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

https://discourse.nixos.org/t/flake-does-not-follow-local-nixpkgs-anymore-even-with-flake-nixpkgs/76052/8

[bryango]

I am aware of the previous discussions and have been using --override-input nixpkgs nixpkgs for some time now. I am still constantly annoyed by the length of these flags and the fact that, without them I may accidentally introduce a bunch of different nixpkgs copies on my tiny system (and this has happened multiple times).

I understand the reproducibility concern for the local registry but it is really helpful for usability. Maybe a good compromise is to add a --use-local-registries flag (and maybe a global option in nix.conf as well) to always respect local registry overrides.

For better reproducibility, we can force the CLI to always print a warning: using local registries for flake inputs when this flag is used, so that people are aware of the caveats.

[kirelagin]

I think #13239 is a reasonable approach, so I would just add override-inputs = nixpkgs=flake:nixpkgs or something like this to my nix.conf, as I pretty much always want to use local nixpkgs.

[tobiasBora]

I think #13239 is a reasonable approach

This basically brings back the issue that #13156 was precisely trying to solve (and the fact that people want to put this in their nix.conf shows that this may actually bring confusion/impurity if we don't find a proper fix), and it is also a fairly dirty solution to "modularity & composablity" since this command will modify the flake.lock file, hence two collaborators with different paths will keep modifying this file.