NIX_PATH is polluted when setting nix.nixPath

[mpickering]

f3a114e

This recent commit means that setting nix.nixPath does not fix the value of NIX_PATH. Now it is also
polluted with this reference to ~/.nix-defexpr/channels which has now caused breakage for me on two different machines.

The original commit didn't have this intent I believe as it was only intended to modify NIX_PATH if nix.nixPath wasn't set.

@dtzWill

[dtzWill]

Eek, sorry! Forest for the trees. So the problem is that currently no matter what nix.nixPath is set to, extraInit will prepend ~/.nix-defexpr/channels which effectively changes the user's observed NIX_PATH.

Previously we incorrectly added unexpanded '$HOME/.nix-defexpr/channels' which is no good although I think mostly caused nix to complain a lot (and lack of channels on NIX_PATH presumably).

The clean-simple solution is to delete the extraInit (and don't put it in sessionVariables as it was either). And then solve that problem as we think best.. basically re-open #38351 and try again.
Probably by ironing out exactly when user's channels should be expected to be on NIX_PATH based on which configurations used.

Thoughts?

[dtzWill]

Err I'll clarify that reverting both my commit and the one for #38351 is meant to be the suggested baseline to solve this from (instead of plumbing more complications) but may not be a good state to actually have master in. We'll sort this out :).

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[dtzWill]

Hmm, I may have misunderstood your issue I'm sorry.

The ability to explicitly set exactly what NIX_PATH ends up as.. seems like a reasonable offering! 😸

If I understand the problem is that now NIX_PATH gets values both when setting nix.nixPath explicitly as well as when nix.nixPath is empty.

It seems fixing this is straightforward enough, the question is what is the desired/expected behavior.
I guess at this point I'd suggest leaving the current behavior to avoid more breakage, but would be good to have an intentional decision here.

And the documentation should likely clarify either way :).

Also, sorry any of this broke things for you!

---

Thoughts? :)

[fricklerhandwerk]

Today I discovered that this change introduced inconsistent behavior, and is therefore even breaking for new users of nix.nixPath. Login as root and the added line for environment.extraInit takes effect, login as a regular user, and it does not.

I've spent a lot of time searching where the difference could come from, but I am at loss here.

There are only two places where environment.sessionVariables is even used:

1. system.build.pamEnvironment
2. environment.variables

system.build.pamEnvironment is used exactly once outside of desktop managers, namely for creating a pam service configuration. I cannot see how exactly this interacts with login and how it may lead to the difference, it is really confusing. environment.sessionVariables end up in the system.build.setEnvironment script as part of environment.variables. Note how extraInit comes afterwards! It sounds improbable that extraInit triggers for root but no one else. So maybe it has something to do with pam?

[fricklerhandwerk]

Oh boy, the description of my experiment was flawed, and that made it more confusing.

Login as root and the added line for environment.extraInit takes effect, login as a regular user, and it does not.

This is not correct. It is true for the following: login as user1 and the line takes effect, su user 2 and the line does not. This is due to __NIXOS_SET_ENVIRONMENT_DONE.

In any case I still perceive the behavior as broken. At first I thought about fixing this the straightforward way and just also check -z $NIX_PATH. But then we still have the inconsistency when creating new shells depending on whether they inherit the environment. It's tricky...

[stale]

I marked this as stale due to inactivity. → More info

[wmertens]

For a fixed NIX_PATH, I create a symlink in the system so that the path remains the same between activations. Here's what I put in a flake:

        {
          nix.nixPath = [
            # Point to a stable path so system updates immediately update
            "nixpkgs=/run/current-system/nixpkgs"
            # Allow using nixos-option to query current config
            "nixos-config=/run/current-system/flake/configuration.nix"
          ];
          system.extraSystemBuilderCmds = ''
            ln -s ${nixpkgs.outPath} $out/nixpkgs
            ln -s ${self.outPath} $out/flake
          '';
          nix.registry.nixpkgs.flake = self.inputs.nixpkgs;
        }

As for updating environment variables, see #161358

[vamega]

I see that extraInit not only adds the the channels to the NIX_PATH if the channels directory exists.

Is it assumed to be then safe to deleted the ~/.nix-defexpr directory if all channels have been removed and the system is running exclusively with flakes?