Home-manager doesn't seem to recognize sessionVariables

I tried this (except I used “kak” instead of “vim”), but it isn’t working for me. After home-manager switch, restarting the terminal and even a reboot, I still get this:

echo $EDITOR
nano

I don’t even know where nano is being set as my editor. I can’t find a statement in home.nix nor configuration.nix.

EDITOR environment variable is defined as nano by default on NixOS:

Also, did you read this entry on HM FAQ? If your current shell is not provided by HM, you need to explicitly source a file for HM session variables to take effect.

That link seems to contradict itself and say the opposite of what you are saying.

First it says:
Home Manager is only able to set session variables automatically if it manages your Bash, Z shell, or fish shell configuration.

Then it says:
If you don’t want to let Home Manager manage your shell then you will have to manually source the ~/.nix-profile/etc/profile.d/hm-session-vars.sh file in an appropriate way.

I DO want to let Home Manager manage my shell, so therefore I don’t have to manually source that file.

But it doesn’t say that I must do something different to let HM manage my shell. That would seem to imply that I don’t need to do anything, that HM automatically manages my shell.

Is that a mistake in the Home Manager Manual?

1 Like

home.sessionVariables are defined in a file named hm-session-vars.sh. If you are in a shell provided by a HM module, this file is already sourced (They are also explicitly sourcing it but it is hidden to the user.). If you are not using a shell provided by a HM module (e.g. shell provided by NixOS) or writing your own HM module for a shell, then you need to source that file yourself to have those sessions variables defined.

So do you have programs.bash.enable or the appropriate optiön for whatever shell yöu use?

Yes. I even have set programs.bash.sessionVariables = {EDITOR = "kak";};, but EDITOR is still defined as nano.

But do you have programs.bash.enable = true as well?

Yes.
#padding to 20 chars

Is it possible to set the EDITOR session variable for bash from Home Manager?

Yes, programs.bash.sessionVariables, though as far as I understand you tried that already…

Are other changes you do in your HM configuration for bash applied correctly?

Can you share more of your config to get a more complete view to it? It feels as if there is something not exactly as it needs to be…

One more person here with similar problems. I’ve set variables in home.sessionVariables, programs.bash.sessionVariables, and systemd.user.sessionVariables and nothing is set once I log in. Using SDDM → i3.

The strange thing is that things like GDK_SCALE etc seem to be having an effect on the UI, so they are being loaded at some point, but then they disappear. bemenu doesn’t recognize PATH updates, and terminals don’t see any of the variables that have been set.

UPDATE: It’s not clear that GDK_SCALE is being used.

UPDATE2: So it looks like the .profile file written by home-manager’s bash module is not executable, and is also owned by root. It’s put into $HOME with a chain of a couple symbolic links which obfuscates this, but this is clearly the reason it’s not working for me at least. Not sure if I’m doing something strange of if this is broken in the unstable channel.

Yes, I have the following in my HM config, and “pfetch” properly runs when opening a terminal, but $EDITOR is not getting set, it is still “nano”.

programs.bash = {
    enable = true;
    bashrcExtra = "pfetch";
    sessionVariables = {
        EDITOR = "kak";
    };
};

I’m hitting this, too. I can tell that hm-session-vars has been sourced (somewhere), but it seems like maybe /etc/set-environment was sourced after. (thus my EDITOR gets replaced with the nixos env default).

Further, there’s an “include guard” at the top of hm-session-vars that would prevent it from fixing EDITOR if it were sourced again later.

I’m probably going to remove the “include guard” and see what happens. I’m wondering if maybe it will just be fixed.

1 Like

Well, I removed the include guard, forgot about it and then later noticed git was using Helix, so I’d say that might be worth pursuing. I’ll try to send a PR for HM to start a discussion soon.

Shell/Bash Digression

I’m also interested in this peculiarity. Note that home.sessionVariables is about “environment variables to always set at login.” In particular, these variables are not set in a Shell session that is not a login session. You can try it out with eg. bash vs. bash --login. If we keep the example of Bash, when using home.sessionVariables and programs.bash.enable = true, HM does the following:

  • write the session variables in ~/.nix-profile/etc/profile.d/hm-session-vars.sh
  • source this file from ~/.profile
  • source ~/.profile (and ~/.bashrc) from ~/.bash_profile

During its startup, Bash will look for ~/.bash_profile when started as a login Shell and for ~/.bashrc when starting as an interactive non-login Shell (cf Bash Startup Files in the Bash Reference Manual), giving the behaviour that we all observe.

Back to this Problem

I don’t know what happens, but I suppose those variables are set correctly at login, but overridden afterwards. This is also what @colemickens’s experiment to remove the “include guard” suggests. The cleanest way to deal with this would be to understand what precisely happens and act there. I’m not good enough with NixOS/HM to figure that out at this point. I can think of two less clean ways to deal with this:

  1. Go for the aforementioned trick to source the ~/.nix-profile/etc/profile.d/hm-session-vars.sh in ~/.bashrc, and this whether HM manages it or not. (If HM manages it, then it should be done through HM’s configuration of course.) The risk of this is that this might pick up on some variables that HM puts in this file for the login, thinking they will be overridden by user-chosen ones afterwards.

  2. For this particular case, put the few variables bindings that are of interest to us directly in ~/.bashrc either through HM or manually. I will go for this one, and probably wait for a cleaner option later on. (There is already an environment.interactiveShellInit in NixOS, why not an interactiveShellVariables or something?)

1 Like

. “/nix/var/nix/profiles/system/etc/profiles/per-user/${USER}/etc/profile.d/hm-session-vars.sh”

to init…

failed
Ventura ERROR

I also just hit this problem. Home Manager now has a pull request that should solve this issue, at least for zsh.

Sorry for necro, but I stumbled upon this post when I came across this problem myself.
Hope this is useful for the next person.
As an addendum to Niols’ post:

The first few lines of hm-session-vars.sh

# Only source this once.
if [ -n "$__HM_SESS_VARS_SOURCED" ]; then return; fi
export __HM_SESS_VARS_SOURCED=1

That VARS SOURCED is set by it’s previous version and part of your session, so new shells wont source the rest of the file where your path gets updated until you log out and in

For your current shell you can:

unset __HM_SESS_VARS_SOURCED ; . .profile
1 Like

I had to close all my existing terminal windows, and only after that I had the expected environment variables available in new terminal windows. I was surprised by this, as I did not think existing windows would affect anything. Posting this in case it helps anyone else who finds this thread.

2 Likes

I did this to add it as $EDITOR. It is working as expected. Try it out:
programs.neovim = {
enable = true;
defaultEditor = true;

defaultEditor = true; is what did the trick