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:
~/.nix-profile/etc/profile.d/hm-session-vars.sh
~/.profile
~/.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.
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?)
. “/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
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.
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