Nixpkgs flake input version

Help
1

I am trying to make a flake that uses the system nixpkgs as an input, but I haven’t had much luck with it yet. I think this should be possible, since release 24.05 mentions something along these lines, but neither that nor setting nix.registry.flake explicitly seems to do the trick.

For example:

> nix eval --impure --expr "<nixpkgs>"
/nix/store/9rc9abg9f664bjfhzfp4cb8mrwh7b5y4-source

> nix flake metadata nixpkgs
Resolved URL:  path:/nix/store/9rc9abg9f664bjfhzfp4cb8mrwh7b5y4-source?lastModified=1746461020&narHash=sha256-7%2BpG1I9jvxNlmln4YgnlW4o%2Bw0TZX24k688mibiFDUE%3D&rev=3730d8a308f94996a9ba7c7138ede69c1b9ac4ae

> nix flake metadata .
Resolved URL:  path:/home/tipson/Dev/testdir
...
Inputs:
└───nixpkgs: github:NixOS/nixpkgs/b3582c75c7f21ce0b429898980eddbbf05c68e55?narHash=sha256-FshoQvr6Aor5SnORVvh/ZdJ1Sa2U4ZrIMwKBX5k2wu0%3D (2025-05-07 00:09:58)

using the trivial flake

{
  outputs = { nixpkgs, ... }: { };
}

I don’t know how that specific nixpkgs gets chosen but:

  • it stays the same through removing/updating the lockfile
  • when i noticed this it was newer than what was used to build the system
  • it stayed the same after bumping my system nixpkgs version
2

It resolves from the flake registry. NixOS sets nixpkgs to refer to your system flake’s nixpkgs input by default, but this might not be the case if you further override it, or somehow disabled that. Your NIX_PATH seems to point to the right place.

This is enabled by this module: NixOS Search

You do still need to nix flake update to update whenever your system updates, but you say you’ve done so.

What does nix flake registry list say?

3

From my understanding It shows the same thing:

> nix registry list
system flake:nixpkgs path:/nix/store/9rc9abg9f664bjfhzfp4cb8mrwh7b5y4-source?lastModified=1746461020&narHash=sha256-7%2BpG1I9jvxNlmln4YgnlW4o%2Bw0TZX24k688mibiFDUE%3D&rev=3730d8a308f94996a9ba7c7138ede69c1b9ac4ae
...
global flake:nixpkgs github:NixOS/nixpkgs/nixpkgs-unstable
...
4

Have you considered --override-input ?

5

Yeah, this looks like a bug

6

nix flake metadata . --override-input nixpkgs $(nix eval --impure --expr "<nixpkgs>") does work, but I feel really silly doing so :slight_smile: . Nice to know as a workaround at least.

7

flake:nixpkgs should work instead of the subcommand

8

Indeed it should, but it does not.

> nix flake metadata . --override-input nixpkgs "flake:nixpkgs"
Resolved URL:  path:/home/tipson/Dev/testdir
...
Inputs:
└───nixpkgs: github:NixOS/nixpkgs/b3582c75c7f21ce0b429898980eddbbf05c68e55?narHash=sha256-FshoQvr6Aor5SnORVvh/ZdJ1Sa2U4ZrIMwKBX5k2wu0%3D (2025-05-07 00:09:58)
9

Which version of nix are you using? do you think Changelog: deprecating channels and indirect flake references is affecting you?

1 Like
10

I am on nixos-unstable, commit 3730d8a at the moment. Looks like on one of my older configurations (bffc22e), it was still working fine, so I might try to bisect it.

The deprecation of indirect references would indeed impact me by the looks of it. It seems quite silly to remove indirect references and forcing fully qualified flake inputs if one wants to keep multiple flakes’ nixpkgs in lockstep.

11

In fairness, due to the dependence on nix flake update this isn’t actually particularly convenient in the only sensible use case for it (i.e. purely local projects, whose flakes are not shared with the outside world).

Of course, the only other reasonable workaround (using a traditional shell.nix/default.nix that depends on the NIX_PATH also being set to the system flake input) is also being deprecated.

I don’t think detsys care at all about this use case here, they’re developing a fork purely for dev purposes on other systems, to be used for shared projects in an organization that adopts flakes across all their projects. If you’re using their fork, consider switching to a nix fork which does cover your use case.

12

Sorry, I misunderstood what he was asking about. I don’t use detsys but I think i’ve been able to narrow it down to nixVersions.nix_2_28: 2.28.2 -> 2.28.3 · NixOS/nixpkgs@50a572e · GitHub .

13

We no longer are using the flake user registry in Nix for flake.nix because it leads to non-reproducible inputs in some cases where user are overwriting nixpkgs with a path and than upload the result into a repository for other people to use. The new behavior will make nix flake update behave the same on every machine independent from the flake registry.

2 Likes
14

Yeah I read up a bit on some of the discussion going around the various issue threads, but I gotta admit I’m still kinda torn on whether I like where we’ve ended up.

If reproducible inputs was the only concern one could easily use a warning or perhaps force that type = "indirect" is written out explicitly.

On the other hand I feel like this considerably hinders the instances where it is desired that the same version of nixpkgs be used by different flakes. Maybe there are multiple users with standalone home-manager configurations, or various devshells. Now, I would need to manually pin these inputs for each one, or use --override-input, which kind of defeats the point of using lockfiles at all.

If someone uploads a flake with registry references by mistake, this is something that should be fixed by them in the repo, but can also be fixed by people using it downstream. Maybe I’m ignorant, but I just don’t see how this behavior would be both impactful and widespread enough to outweigh the other use cases it enables.

15

It should be still possible

environment.etc."nixpkgs".source = self.inputs.nixpkgs; should allow you to do this:

  inputs.nixpkgs.url = "path:/etc/nixpkgs";
16

I wouldn’t be too opposed to using this, but it doesn’t seem to be working. Even if its running with impure, it either complains that its a symlink, or the etc activation fails.

17

Mhm. Okay but even when it worked before it is somewhat brittle because those store paths that your flake referenced can be garbage collected without any warning. Since it also still requires to run nix flake update manually anyway to keep it in sync some custom script that updates flake.nix from some central reference source might be an alternative. I.e something like github:NixOS/nixpkgs/<commit>. The advantage of this is also that is now portable across multiple systems.

1 Like