IIUC this change will Nix to set its hardcoded default value.
See https://github.com/search?q=repo%3ANixOS%2Fnix%20getDefaultNixPath&type=code

If a system has not been manually cleaned after disabling nix.channel.enable, this will cause the old channel data to be used again.
For this reason I don't think this is a good workaround, unless you've removed the data.
Maybe it's good enough if the activation script put a big fat warning if it finds that the data still exists and tells the user that their option is ineffective until they remove it?

The actual root cause is in Nix. Unfortunately it's non-trivial because of implementation design, and legacy.

• Broken NIX_PATH tracking issue nix#9574

cc @fricklerhandwerk

IIUC this change will Nix to set its hardcoded default value.
See github.com/search?q=repo%3ANixOS%2Fnix%20getDefaultNixPath&type=code

From my testing, NIX_PATH takes precedence over that hardcoded default. If I unset NIX_PATH, then indeed channels from the default config are picked up, but if I set NIX_PATH to empty then no channels can be used.

IIUC when channels.enable = false, NIX_PATH is set to empty, and therefore I'd say it's the expected behaviour.

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

https://discourse.nixos.org/t/disabling-channels-breaks-nix-path-resolution/34825/3

@roberth

the channel data still exists in /nix/var/... and can therefore still be found by Nix,

If a system has not been manually cleaned after disabling nix.channel.enable, this will cause the old channel data to be used again.

As stated by @nbdd0121, this is not true. When NIX_PATH is set, which is the current behavior no matter if channel is enabled, it is used instead of the builtin default value that you mentioned. Thus the old channel data is still ignored.

It's already covered by the test nixosTests.installer.switchToFlake, which still succeeds on this PR.

Ok, I suppose we could apply this change while NixOS/nix#9574 isn't resolved then.
Instead of deleting the line, could you comment it out, and put a comment that references the issue?

@ofborg test installer.switchToFlake

Ok, I suppose we could apply this change

Or maybe not, because of nix-shell --pure, which unsets NIX_PATH, among almost everything.
Ironic.

$ export NIX_PATH=test=$PWD

$ nix-shell --pure -I nixpkgs=. -p hello --run 'env | grep NIX_PATH'

$

Or maybe not, because of nix-shell --pure, which unsets NIX_PATH, among almost everything. Ironic.

$ export NIX_PATH=test=$PWD

$ nix-shell --pure -I nixpkgs=. -p hello --run 'env | grep NIX_PATH'

I don't think this matter. --pure is an explicit way to mimic Nix's sandbox-ed building environment, which of course unset as much as possible from your shell environment. As a module option, it's configuring the default shell environment, and it cannot forbid user or program from changing it to another way.
Also that, if you are really running nix in a nix-shell, I'd assume you are debugging a builder which calls nix, it's problematic anyway due to not-so-good isolation. It's the last thing to consider that whether outer configuration takes effect on the inner Nix.

@oxalica The problem is that an empty NIX_PATH makes Nix use the default, which then includes the channels unless you have them deleted..

@oxalica The problem is that an empty NIX_PATH makes Nix use the default, which then includes the channels unless you have them deleted..

My argument is that, NIX_PATH is set by the module already. It is NOT empty without intentional setting/unsetting it (like nix-shell or env). It is not possible and unnecessary to prohibit user from reverting it at will.

For example, EDITOR= sudoedit /file or nix-shell --pure --run '/path/to/sudoedit' will call nano as fallback, even through programs.nano.enable = false; programs.vim.defaultEditor = true;. This is not considered a problem. Because the user deliberately unsetting the environment from the system configuration, and want to use the "true default" of sudoedit.

The problem is that the "true default" behavior breaks the intended effect of the option. It's a system option, so it will be perceived to have authority over the system.

Arguably that wouldn't be as big of a deal if the activation script were to print a big fat warning that commands such as nix-shell --pure will still be able to find the old channel data (and suggest how to remove that).
I think that would be an ok solution.

a warning would go a long way to helping users out here. previously, i was setting:

nix.nixPath = [ "nixpkgs=/path/to/my/dev/fork/of/nixpkgs" ];

this was working for quite a while. eventually though i set nix.channels.enable = false; because i don't use channels, and this seems to have had the unintended side-effect of breaking all my #!nix-shell scripts (though, i'm actually not sure if it was that change, or something else?)

anyway, there are people out there setting nix.nixPath for reasons entirely unrelated to channels. i ran into another person in the Nix Matrix room who hit this yesterday. nothing in the name of that option suggests it's about channels. so if there's no obvious "correct" behavior to choose, can we at least raise a warning if nix.nixPath is non-default while nix.channels.enable = false?

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

https://discourse.nixos.org/t/how-to-get-a-derivation-path-for-nixpkgs/41231/4

IIUC when channels.enable = false, NIX_PATH is set to empty, and therefore I'd say it's the expected behaviour.

@nbdd0121 nix.settings.nix-path is setting the nix-path setting in nix.conf, which then causes the behavior wrt the NIX_PATH environment variable being discussed.

Have we considered just nuking (or at least moving/automatically backing up/restoring a la nix-darwin) the channel data?

Fixed by #254405

Fixed by #254405

Can you explain, please? For me it looks like it was partially reverted by https://github.com/ryan4yin/nix-config/pull/123/files but as another comment stated (don't know why it's gone/not showing up for me?):

Nix path is set to: nixpkgs=flake:nixpkgs then but but action e.g. "nix-shell -p jq" fail with:

error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)

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

Fixed by #254405

Can you explain, please? For me it looks like it was partially reverted by https://github.com/ryan4yin/nix-config/pull/123/files but as another comment stated (don't know why it's gone/not showing up for me?):

Nix path is set to: nixpkgs=flake:nixpkgs then but but action e.g. "nix-shell -p jq" fail with:

error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)

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

Sorry, I made a mistake, this issue has not been resolved yet.

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

https://discourse.nixos.org/t/24-05-add-flake-to-nix-path/46310/11

I see two ways to move this forward without breaking users' expectations.

• Either print a clear warning in the activation script if the channel data still exists in /nix/var/... and can therefore still be found by Nix,

@roberth I agree. I implemented this suggestion in #323613, if you'd like to have a look.

Note that since NixOS/nix#11079 made its way into Nix 2.24, the current behavior of exporting the NIX_PATH environment variable even when nix.nixPath is empty seems to no longer be appropriate.

An empty value now effectively prevents extra-nix-path from having any effect, so the option set by the installer is ignored since Nix 2.24, which I have found to be very confusing until I stumbled upon the aforementioned Nix PR.

This can detect and fix the problem in a Zsh RC file:

programs.zsh.shellInit = ''(( ''${+NIX_PATH} )) && [[ -z ''${NIX_PATH} ]] && unset NIX_PATH'';

The diff for the temporary merge commit c0b482cb974cca649d183ab4914b05f546c59482 is empty.
The changes in this PR have almost certainly already been merged to the target branch.