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.
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.
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.
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.
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.
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:
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.
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?)
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
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.