nixos/flake: set up NIX_PATH and system flake registry automatically #254405

lf- · 2023-09-10T12:45:46Z

Currently there are a bunch of really wacky hacks required to get nixpkgs path correctly set up under flake configs such that nix run nixpkgs#hello and nix run -f '<nixpkgs>' hello hit the nixpkgs that the system was built with. In particular you have to use specialArgs or an anonymous module, and everyone has to include this hack in their own configs.

We can do this for users automatically.

I have tested these manually with a basic config; I don't know if it is even possible to write a nixos test for it since you can't really get a string-with-context to yourself unless you are in a flake context.

cc @RaitoBezarius

Description of changes

Things done

IreneKnapp

overall looks great, I want this!

IreneKnapp · 2023-10-02T08:30:35Z

nixos/modules/misc/nixpkgs.nix

+        default = false;
+
+        description = mdDoc ''
+          Whether to create /etc/nix/inputs/nixpkgs as a symlink and set


This could use more documentation about where the symlink points to. I mean, I assume it points to the path to the derivation that nixos is being built out of, but there must be an appropriately precise way to say that...

IreneKnapp · 2023-10-02T08:32:59Z

nixos/modules/misc/nixpkgs.nix

+        default = false;
+
+        description = mdDoc ''
+          Whether to set nixpkgs in the local flake registry and disable the


Similarly, I assume this points to the derivation nixos is built out of, but find some precise way to say that. Also specify explicitly whether this option relies on the /etc/nix/inputs/nixpkgs symlink to exist or not.

Also, it's called the system registry not the local registry. Since that term is vague and confusing and doesn't help a user to understand why they'd want this option turned on, by all means keep the present wording about "local" as well, but do use it in conjunction with the official name.

Ah, not quite the one nixos is built out of, which means my docs are bad. I will write better ones than I wrote while originally writing this whilst tired at nixcon tomorrow :)

Apparently I misunderstood what you wrote because it was 2am. This option doesn't require /etc/nix/inputs/nixpkgs to exist, and is completely independent of the other option.

it sure was 2am <3

lf- · 2023-10-02T21:43:28Z

Alright, I have pushed a change rewriting the documentation to have examples and to use more clear wording. I have also turned it on by default.

The reasoning for enabling it by default on flake configurations is that we do things that are suboptimal for closure size by default, for example environment.noXlibs = false;, documentation.enable = true;, and it seems much more important to make the out of the box experience better for machines that might be used interactively.

This change only affects systems built with flakes.

IreneKnapp

looks solid to me! note that this is by way of peer review, I'm not a committer, somebody else will need to approve it

IreneKnapp · 2023-10-02T22:29:20Z

nixos/modules/config/nix.nix

@@ -332,6 +332,16 @@ in
                always allowed to connect.
              '';
            };
+
+            flake-registry = mkOption {
+              type = types.str;


don't you mean nullOr str?

Yes, I didn't realize null was coerced to empty string.

IreneKnapp · 2023-10-02T22:31:27Z

nixos/modules/misc/nixpkgs.nix

+
+        description = mdDoc ''
+          Whether to create `/etc/nix/inputs/nixpkgs` as a symlink to the version of nixpkgs that
+          the NixOS system was built with and set `NIX_PATH` to include `/etc/nix/inputs/nixpkgs`.


just to be absolutely clear: the symlink points to a path in the store, right?

Yep. I will word this more carefully.

IreneKnapp · 2023-10-02T22:33:43Z

nixos/modules/misc/nixpkgs.nix

+
+        description = mdDoc ''
+          Whether to pin nixpkgs in the system-wide flake registry (`/etc/nix/registry.json`) to the
+          version of nixpkgs that the NixOS system has been built with.


so the understanding I get from this is that it replicates the protocol, URL, etc but pins based on rev. correct? I still feel like there could be a bit more wording to say so explicitly, but it's good as-is.

Nope. It is a string-with-context that introduces a simple dependency:

nix-repl> nixosConfigurations.micro.options.nix.registry.value.nixpkgs.to { path = "/nix/store/c8cz4q0y6jw9qvjwk45nf6pvwysj7yn6-source"; type = "path"; } nix-repl> :p builtins.getContext nixosConfigurations.micro.options.nix.registry.value.nixpkgs.to.path { "/nix/store/c8cz4q0y6jw9qvjwk45nf6pvwysj7yn6-source" = { path = true; }; }

ah! that's nice and simple. the clearest way to say that might be "by referencing it in the store"?

IreneKnapp · 2023-10-02T22:35:01Z

nixos/modules/misc/nixpkgs.nix

+          version of nixpkgs that the NixOS system has been built with.
+
+          This also sets a default to disable the global (online) flake registry due to
+          <https://github.com/NixOS/nix/issues/9087>.


ah good call

Bad call: unnecessary breaking change. Why not fix the bug instead?

I don't want to try getting anything into Nix after a one line change to fix nix-shell in shebangs by a former coworker continues to sit unreviewed for going on two years now, in spite of repeated prodding for reviews including by back channels.

I understand the Nix team has been improving things, and I think more prompt reviews generally happen now but I'm still not interested.

I can remove the workaround because the bug isn't that bad.

@lf- i have an interest in the shebangs features, but I am not finding the referenced shebang PR. (my own effort in bringing shebangs to nix-command took more than two years with 5189, so I understand the patience can get worn out)

i had it written down somewhere; it's NixOS/nix#5088

lf- · 2023-10-03T00:51:51Z

I have done a final pass through the docs. I am not sure if they are too verbose, but even if they are, usually we have the opposite problem and I have rarely thought that of module docs.

IreneKnapp · 2023-10-03T03:38:43Z

the latest revision of the docs looks great. thanks for indulging me! I know I tend to prefer more verbose docs than others do, but I feel that a lot of flake semantics are under-documented and I'd much rather not have to guess at these details.

Artturin · 2023-10-03T07:12:40Z

The diff looks very weird, are there formatting changes or something?

Related PR #197424

lf- · 2023-10-03T07:17:33Z

The diff looks very weird, are there formatting changes or something?

Related PR #197424

Yes. I moved the whole existing config= contents right one indent, put it in a mkMerge, and added my own things. When I rebased I did these changes manually because git had made such an absolute dog's breakfast of the diff and I couldn't make any sense of it.

I don't know what made git fail so hard on this PR's diff, but I am sorry it is annoying to review.

Artturin · 2023-10-03T07:28:52Z

Hiding the whitespace changes makes it better

rightmost icon

nixos/modules/misc/nixpkgs.nix

tomberek

blocking: /etc/nix/inputs/nixpkgs is awkward, please examine some other possibilities mentioned above
thought: having nixpkgs.flake.setNixPath interacting with nix.nixPath (same with nixpkgs.flake.setFlakeRegistry / nix.registry) might cause confusion. There are then two ways to do the same thing, which takes precedence, etc. Here i don't yet know of solid suggestion; there is merit to having it in both option sets.

nixos/modules/misc/nixpkgs.nix

RaitoBezarius

This has been reviewed, scrutinized for a long time, this change makes a lot of sense and improves the statut-quo. Let's iterate from now on.

stale

No longer needed via NixOS/nixpkgs#254405

totoroot · 2024-02-29T08:12:25Z

Just for reference, in case someone is looking for the change that caused their flake-based NixOS systems to no longer rebuild.

Since I previously had nix.registry.nixpkgs.flake set in my flake config, I got the following error when trying to rebuild my system:

       error: The option `nix.registry.nixpkgs.to.path' has conflicting definition values:
       - In `/nix/store/1gpgihsi21bni03hy6i5ccw9lfrhnbqi-source/nixos/modules/config/nix-flakes.nix': "/nix/store/84q33bh989jr3hadc8jj2rsz6ax5cqyj-source"
       - In `/nix/store/1gpgihsi21bni03hy6i5ccw9lfrhnbqi-source/nixos/modules/misc/nixpkgs-flake.nix': "/nix/store/1gpgihsi21bni03hy6i5ccw9lfrhnbqi-source"
       Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

The suggested use of lib.mkForce or lib.mkDefault is not advisable.
Instead just remove the manual NIX_PATH override in your config, as this is now handled automatically.

If you do not wish to do so, you can also disable the newly added option, as described in the release notes (look for NIX_PATH).

To disable this, set nixpkgs.flake.setNixPath and nixpkgs.flake.setFlakeRegistry to false.

IMO the documentation of this change in the release notes is good, but users might still look for this error in the issues and PRs of the nixpkgs repository, so I thought I'd mention it.

No longer needed since NixOS/nixpkgs#254405 got merged See NixOS/nixpkgs#254405 (comment) for more information

NixOS/nixpkgs#254405

Since <NixOS/nixpkgs#254405> was merged, `nix.nixPath` is set when you use `lib.nixosSystem`

nixos-discourse · 2024-04-21T18:35:48Z

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

https://discourse.nixos.org/t/use-a-system-nixpkgs-version-in-a-flake/43784/3

- Don't auto-optimise-store by default - We should avoid arbitrary "sane defaults" in this template, as nixpkgs already has pretty sane defaults nowadays - Simplify registry+nixPath - Instead of using a file as indirection (to avoid staleness), indirect it through the registry using `flake:nixpkgs` - Add a comment about NixOS/nixpkgs#254405, which all this by default for nixpkgs - Disable channels and flake registry by default

nixos-discourse · 2024-05-21T00:14:16Z

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

https://discourse.nixos.org/t/python-applications-set-pythonpath-how-is-that-not-a-nix-anti-pattern/45736/4

arianvp · 2024-06-08T15:34:26Z

Hmm should we also enable flakes when using nixpkgs.lib.nixosSystem? Since this PR landed you get the following super confusing error message when you try to use nix-shell -p on a NixOS system built with lib.nixpkgs.nixosSystem.

nix-shell -p aws
error:
       … <borked>

         at «none»:0: (source not available)

       … while calling the 'import' builtin

         at «string»:1:18:

            1| {...}@args: with import <nixpkgs> args; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (aws) ]; } ""
             |                  ^

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: experimental Nix feature 'flakes' is disabled; use '--extra-experimental-features flakes' to override

[ssm-user@ip-172-31-1-45:/var/log]$ nix-shell -p aws --show-trace
error:
       … while calling anonymous lambda

         at «string»:1:1:

            1| {...}@args: with import <nixpkgs> args; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (aws) ]; } ""
             | ^

       error: experimental Nix feature 'flakes' is disabled; use '--extra-experimental-features flakes' to override
       ```

lf- · 2024-06-08T17:20:18Z

@arianvp probably yes. I've been meaning to submit that exact change for like, months.

name-snrl · 2024-06-08T18:24:31Z

Maybe we just need to replace registry link to a path?

lf- · 2024-06-08T18:36:08Z

Maybe we just need to replace registry link to a path?

no, that is broken. the environment variable won't be updated in existing processes so you need at minimum a symlink indirection. i had one of those twice in the revision history of this pr if you want to see, and the current method is the simplest and most robust possible with the singular caveat that the resulting system needs flakes enabled.

DavHau · 2024-08-25T12:33:22Z

I appreciate this effort, but as long as nix allows pointing inputs to the local registry, this change practically seems to do more harm than good.

I think we should consider at least turning the setFlakeRegistry off by default and add a big fat warning to the docs about the consequences this can have on flake.lock updates.

I ended up publishing broken flakes for some time now without noticing and I'm probably not the only one.

Implementing a performance improvement (less networking/fetching) with the cost of introducing breakages in the wild doesn't seem to be a tradeoff worthwhile to me.

I understand that there are opinions on how flake inputs should never point to the (local) registry, and I'm not opposed to that.
But still, many people don't know that and the tooling doesn't prevent or warn about it.
At the same time the breakages introduced here are not obvious at all, and only detected after the flake gets published and re-used by another person.

It would be much better if nix itself is fixed first, in order to not allow local registry flake inputs or warn about using them, before breaking many peoples setups by such change.

An alternative approach could be to point the registry override to github:nixos/nixpkgs/${inputs.nixpkgs.rev}.
This will lead to a permanently cached nixpkgs as well without breaking lock file updates.

lf- · 2024-08-25T19:51:50Z

Here's the lix bug number to do what you describe. https://git.lix.systems/lix-project/lix/issues/170

Don't write flakes that use registry indirect inputs. They were always broken regardless of this change because you have no idea which version of nixpkgs they will update to when someone else runs nix flake update. If you really are motivated, you can set the registry to point to be a github input type and pull the metadata out of flake.lock because I believe it never makes it into inputs or at least definitely doesn't make it into nixpkgs' self so we could never have implemented this here.

I think that people who work on broken flakes regularly should consider setting up the necessary custom code to allow them to do that safely and disable this feature. Or fix the flakes. You can absolutely see when you nix flake update and it did the wrong thing. My point here is that working on broken flakes that use the registry is the exceptional case and I've seen a lot of nix support questions in my time; I believe you to be the second one to complain about this, compared to probably a dozen or more times I've had to tell people how to set up NIX_PATH which this change eliminates completely.

I don't think we should regress the default user experience (which, especially NIX_PATH being correct by default has completely eliminated a whole class of support issues to the extent that I've forgotten this was ever a problem). I would especially not advise blocking these UX improvements on changes in the nix implementation because those do not get to users quickly (even with Lix, releases have a long latency to get fixes out).

lf- · 2024-08-25T19:54:35Z

As for your suggestion, it's broken if you have a local or private fork of nixpkgs. It's plausible it would cause redownloads as well if that commit is contained within a fork. Shipping it would be a regression, when the actual fix is making the nix implementations refuse to do registry indirect flake inputs.

This isn't just a performance improvement. It's a correctness improvement. It makes it so that if you bring stuff in with nix-shell today and open a nested shell tomorrow, the stuff will be compatible with each other.

arianvp · 2024-08-25T20:35:55Z

FWIW personally I was very surprised that nix run nixpkgs#hello didn't give me the latest version of hello on my system. I do not think this is the greatest default and it's also very different from pre-flakes world.

Namely I could do nix-channel --update; nix-shell -p mypackage before adding it to my nixos config to try out if I liked the new version.

nix shell nixpkgs#mypackage does not do the same anymore. It always gets an old version.

For that reason I would also prefer setting setFlakeRegistry to false by default.

lf- · 2024-08-25T21:07:40Z

To me, having versions of nixpkgs mismatched with the config is always unexpected behaviour because I expect nixos-rebuild switch to always be a no-op unless I changed something visible to git. It's very easy to e.g. do a channel update and forget to run nixos-rebuild (or it fails) and have it be non obvious this has happened. A workflow where there's only one nixpkgs at play is more intuitive for new users, as evidenced by flake users having channel problems completely vanishing from support rooms after this change.

If I wanted the latest version of something, I would use, pre flakes, nix-shell -I nixpkgs=channel:nixos-unstable -p blah or with flakes, nix shell github:nixos/nixpkgs/nixos-unstable#blah. My viewpoint is the computer should never do anything under your nose so if you have a command that did something one day and then you go to bed and run it again the next day, it should do the same thing and you should have to ask for something different if that's desired.

Semantically, nixpkgs in the registry and <nixpkgs> mean "give me a nixpkgs, don't worry about which one". And there's two logical choices, either latest (modulo caching behaviour!! which makes it more confusing) or the one you have pinned.

Now that being said, the detsys and lix installer (if flakes are on) both set nixpkgs=flake:nixpkgs in NIX_PATH because channels have horrible UX. It also doesn't automatically pin it for you. But this is sensible for UX: "give me some nixpkgs" should mean the same thing across flakes and non flakes and it was confusing it wasn't the case before, regardless of what it's actually pointed to and whether it's pinned or not.

If you don't like it, turn it off. But I would really like to preserve the status quo in which this support problem is gone and the average user doesn't have to think about more than one version of nixpkgs.

NixOS/nixpkgs#254405 Signed-off-by: Roman Volosatovs <[email protected]>

These are sensible defaults we generally want across all configurations -- home-manager, NixOS, nix-darwin. Note: NixOS (and nix-darwin) recently gained some defaults that we don't add here: NixOS/nixpkgs#254405

nixos-discourse · 2024-12-03T17:35:02Z

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

https://discourse.nixos.org/t/start-a-nix-shell-from-unstable-channel/36227/4

github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: documentation This PR adds or changes documentation 8.has: changelog 8.has: module (update) This PR changes an existing module in `nixos/` labels Sep 10, 2023

ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-darwin: 1 10.rebuild-linux: 1-10 labels Sep 10, 2023

lf- force-pushed the jade/nix-path-flakes branch from 2078be3 to 3120b3e Compare October 1, 2023 02:36

ofborg bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Oct 1, 2023

lf- force-pushed the jade/nix-path-flakes branch from 3120b3e to 8651130 Compare October 2, 2023 08:23

IreneKnapp reviewed Oct 2, 2023

View reviewed changes

ofborg bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Oct 2, 2023

lf- force-pushed the jade/nix-path-flakes branch 3 times, most recently from e0c648f to bc3b186 Compare October 2, 2023 21:42

lf- requested a review from IreneKnapp October 2, 2023 21:43

lf- changed the title ~~nixos/flake: options to set up registry and nixPath for flake configs~~ nixos/flake: setup NIX_PATH and system flake registry automatically Oct 2, 2023

IreneKnapp reviewed Oct 2, 2023

View reviewed changes

lf- force-pushed the jade/nix-path-flakes branch from bc3b186 to fd80a9f Compare October 3, 2023 00:50

Artturin requested a review from roberth October 3, 2023 07:11

Artturin reviewed Oct 3, 2023

View reviewed changes

nixos/modules/misc/nixpkgs.nix Outdated Show resolved Hide resolved

lf- force-pushed the jade/nix-path-flakes branch from fd80a9f to 0c919c2 Compare October 18, 2023 21:55

tomberek previously requested changes Oct 21, 2023

View reviewed changes

nixos/modules/misc/nixpkgs.nix Outdated Show resolved Hide resolved

lf- force-pushed the jade/nix-path-flakes branch from 0c919c2 to ec806b7 Compare November 11, 2023 03:50

RaitoBezarius approved these changes Feb 25, 2024

View reviewed changes

RaitoBezarius merged commit 5337ff6 into NixOS:master Feb 25, 2024
21 checks passed

Kidsan added a commit to Kidsan/nixos-config that referenced this pull request Feb 28, 2024

flake: remove manual nixpath override

22f6147

No longer needed via NixOS/nixpkgs#254405

totoroot added a commit to totoroot/dotfiles that referenced this pull request Feb 29, 2024

Remove manual registry entry for nixpkgs in flake

4b01299

No longer needed since NixOS/nixpkgs#254405 got merged See NixOS/nixpkgs#254405 (comment) for more information

lf- mentioned this pull request Feb 29, 2024

Building an ISO from a flake doesn't ensure that experimental-feature flakes is enabled, so <nixpkgs> does not evaluate #292465

Open

GaetanLepage added a commit to GaetanLepage/nix-config that referenced this pull request Mar 6, 2024

flake.nix: remove now useless nix.nixPath setting

39c272e

NixOS/nixpkgs#254405

name-snrl added a commit to name-snrl/nixos-configuration that referenced this pull request Apr 6, 2024

nix: remove nixPath option

cfa98cd

Since <NixOS/nixpkgs#254405> was merged, `nix.nixPath` is set when you use `lib.nixosSystem`

ryan4yin mentioned this pull request Apr 20, 2024

fix: option `nix.registry.nixpkgs.to.path' has conflicting definition ryan4yin/nix-config#123

Merged

zendo mentioned this pull request May 7, 2024

nix-channel: do not set empty nix-path when disabling channels #273170

Open

13 tasks

arianvp mentioned this pull request Jun 8, 2024

nix-shell -p is broken when using nixpkgs.lib.nixosSystem #318300

Open

rvolosatovs added a commit to rvolosatovs/nixelium that referenced this pull request Sep 18, 2024

feat: switch to nixpkgs.flake.setFlakeRegistry

bc35580

NixOS/nixpkgs#254405 Signed-off-by: Roman Volosatovs <[email protected]>

rvolosatovs mentioned this pull request Sep 18, 2024

feat: switch to nixpkgs.flake.setFlakeRegistry rvolosatovs/nixelium#76

Merged

rvolosatovs added a commit to rvolosatovs/nixelium that referenced this pull request Sep 18, 2024

feat: switch to nixpkgs.flake.setFlakeRegistry

2beabc0

NixOS/nixpkgs#254405 Signed-off-by: Roman Volosatovs <[email protected]>

nixos/flake: set up NIX_PATH and system flake registry automatically #254405

nixos/flake: set up NIX_PATH and system flake registry automatically #254405

Conversation

lf- commented Sep 10, 2023

Description of changes

Things done

IreneKnapp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lf- commented Oct 2, 2023

IreneKnapp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lf- commented Oct 3, 2023

IreneKnapp commented Oct 3, 2023

Artturin commented Oct 3, 2023

lf- commented Oct 3, 2023 • edited Loading

Artturin commented Oct 3, 2023

tomberek left a comment

Choose a reason for hiding this comment

RaitoBezarius left a comment

Choose a reason for hiding this comment

totoroot commented Feb 29, 2024

nixos-discourse commented Apr 21, 2024

nixos-discourse commented May 21, 2024

arianvp commented Jun 8, 2024 • edited Loading

lf- commented Jun 8, 2024

name-snrl commented Jun 8, 2024 • edited Loading

lf- commented Jun 8, 2024

DavHau commented Aug 25, 2024 • edited Loading

lf- commented Aug 25, 2024

lf- commented Aug 25, 2024 • edited Loading

arianvp commented Aug 25, 2024

lf- commented Aug 25, 2024

nixos-discourse commented Dec 3, 2024

lf- commented Oct 3, 2023 •

edited

Loading

arianvp commented Jun 8, 2024 •

edited

Loading

name-snrl commented Jun 8, 2024 •

edited

Loading

DavHau commented Aug 25, 2024 •

edited

Loading

lf- commented Aug 25, 2024 •

edited

Loading