nix.registry.nixpkgs.to.path defined multiple times within nix-darwin itself

[sellout]

8714f9e is a breaking change. When I darwin-rebuild build at or after this commit, I get the following error.

error: The option `nix.registry.nixpkgs.to.path' is defined multiple times while it's expected to be unique.

Definition values:
- In `/nix/store/bf…4i-source/modules/nix': "/nix/store/4a…rx-source"
- In `/nix/store/bf…4i-source/modules/nix/nixpkgs-flake.nix'
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

• modules/nix/default.nix
• modules/nix/nixpkgs-flake.nix

Both of these locations use mkDefault, but the latter was added just a week ago in 8714f9e.

My config sets nix.registry.nixpkgs.flake = inputs.nixpkgs. Removing that setting allows my configuration to build, but the issue is that my nix.registry and nix.settings are shared between my configs for nix-darwin, NixOS, and Home Manager. This change seems to make it so I can’t share them (or at least all of them) any more.

But perhaps there is some other change I can make to the config to maintain cross-compatibility?

[emilazy]

Yeah, NixOS does something quite bad here and we inherited it, but slightly different, in a way that breaks things…

Ideally the NixOS module should be improved but please try #1083 which should make us suboptimal in the same way. Sorry for not catching this before the merge.

[mcgilly17]

Thanks for the quick update @emilazy, and thank you for your work on nix-darwin! With the latest update, are we then safe to upgrade to sequoia if we have run a build prior to upgrading?

[emilazy]

As long as you see the darwin-rebuild switch error message, run the command it quotes, and manage to successfully darwin-rebuild switch after that, you should be good to upgrade.

[mcgilly17]

Worked like a charm. Thanks @emilazy.

[emilazy]

Uh, I just noticed this is on the Nixpkgs flake registry pinning stuff. Not sure if you intended to comment here but it’s not related to the Sequoia update at all, FWIW :)

[antoineco]

@sellout not a long-term solution, but if you set nixpkgs.registry.nixpkgs.flake manually, I believe that the most sensible path to avoid your error for now is to additionally set:

  nixpkgs.flake = {
    setFlakeRegistry = false;
    setNixPath = false;
  };

[mcgilly17]

Uh, I just noticed this is on the Nixpkgs flake registry pinning stuff. Not sure if you intended to comment here but it’s not related to the Sequoia update at all, FWIW :)

Oh right, sorry @emilazy. The error ocurred at the same time as I was going through the upgrade process for sequoia. I assumed incorrectly that they were connected! It is all working now, which is fantastic.

[evelant]

@antoineco What does adding that config do? Any potential problems to look out for when doing that?

[antoineco]

@evelant it will prevent nix-darwin from adding:

1. A custom entry for nixpkgs to the Nix registry that points to the store path of the nixpkgs source that was used to build your current system revision. (By default, nixpkgs is a symbolic reference to github:NixOS/nixpkgs/nixpkgs-unstable.)

   Mostly useful if you want nix run 'nixpkgs#something' to run packages from the same nixpkgs revision as you used in nix-darwin

2. The entry nixpkgs=flake:nixpkgs to your NIX_PATH, which is directly related to the registry reference above.

   Mostly useful if you rely on the "legacy" <nixpkgs> lookup path in some places but have channels explicitly disabled. E.g. import <nixpkgs> in a shell.nix. If you only use flakes, this is irrelevant.