NixOS to HomeManaget migration doesn't show few applications in PATH

I have migrated gh and git from NixOS options to home-manager options.

Now both the programs aren’t available in PATH.:smiling_face_with_tear:
How to solve this?

What options did you set?

If your configuration is actually set up to install them, note this entry in the FAQ: Home Manager Manual

I changed my git and gh programs from NixOS options to Home Manager options and now the gh and git commands aren’t available in the PATH. Also I have mentioned my bash and fish shells in HM, but still I’m facing this problem

Here’s also an anomaly I faced:
Also when i try to change a value in git inside a nis shell with git and gh,

git config --globaal user.name "myname"

It doesn’t get added to the config it seems, because even after tryig repeatedly git showing author details not set and asking me to set it again.

My Guess, HM made the config file symlink from the nix store and thus the above command isn’t working.

But I still don’t understand why gh and git isn’t showing up in my environment.
I also added migrated fish the same way from NixOS options to HMOptions but it is being shown in environment(not the configuration options though), but all other package options like gh git firefox aren’t available in the user environment.

When you say “I moved from X to Y”, what exact changes did that incur?

Please share the actual code, and not some phrases describing your actions.

Also, are you using HM as a system module or standalone? If the former, what is the status of the activation service? (systemctl status home-manager-$USER.service)

In general, once you have programs.git.enable = true in HM, HM assumes you will use HM to manage the git configuration, which also means that git config in a “writing” manor will not work anymore, I would expect it to error though.

2 Likes

Sorry for not giving out enough info earlier. I’m using HM as NixOS module.
Also the status check command u gave shows this:

ksvnixospc@nixos ~> systemctl status home-manager-$USER.service
× home-manager-ksvnixospc.service - Home Manager environment for ksvnixospc
     Loaded: loaded (/etc/systemd/system/home-manager-ksvnixospc.service; enabled; preset: ignored)
     Active: failed (Result: exit-code) since Fri 2010-01-01 05:31:11 IST; 15 years 5 months ago
 Invocation: 5d71fa1fa34c418b9e76bbe6d2bbdeeb
    Process: 737 ExecStart=/nix/store/8axxcgpnr78xkhy46yy2dxf5nwjwswv8-hm-setup-env /nix/store/7i6dmf98rq1cssg0kcv1fzv4i5kdqi09-home-manager-generation (code=exited, >
   Main PID: 737 (code=exited, status=1/FAILURE)
         IP: 0B in, 0B out
         IO: 38.8M read, 0B written
   Mem peak: 43.4M
        CPU: 366ms

Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]: - Move or remove the above files and try again.
Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]: - In standalone mode, use 'home-manager switch -b backup' to back up
Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]:   files automatically.
Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]: - When used as a NixOS or nix-darwin module, set
Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]:     'home-manager.backupFileExtension'
Jan 01 05:31:11 nixos hm-activate-ksvnixospc[932]:   to, for example, 'backup' and rebuild.
Jan 01 05:31:11 nixos systemd[1]: home-manager-ksvnixospc.service: Main process exited, code=exited, status=1/FAILURE
Jan 01 05:31:11 nixos systemd[1]: home-manager-ksvnixospc.service: Failed with result 'exit-code'.
Jan 01 05:31:11 nixos systemd[1]: Failed to start Home Manager environment for ksvnixospc.
Jan 01 05:31:11 nixos systemd[1]: home-manager-ksvnixospc.service: Consumed 366ms CPU time, 43.4M memory peak, 38.8M read from disk.
lines 1-21/21 (END)

So problem is HM not getting started?
could it be possible that old config files are affecting this?

If so I saw “-b backup” flag for homemanager standalone method(not nixos module).
Is there any such flags etc that will work with NixOS modules?

here’s my config files repo for reference:

Yep. If you use journalctl -e --unit home-manager-$USER.service you can see what file it’s complaining about. It’s probably best to just delete whatever existing file it’s refusing to overwrite (after you check there’s nothing important in it).

1 Like

I’m outside now, I’ll try once I reach my laptop back.
Before that I went to check this:
I haven’t touched any rc files or any configurations. I just configured few shell alias and default shell via NixOS only.
So deleting any conflicting file won’t be a problem right?

We do not know what files are conflicting and why.

Whether it is safe to simply delete them or making sure that the generated configuration files from HM are equivalent is up to you to decide.

Thats why TLater suggested to first check that there is nothing important in those files.

1 Like

Thanks a lot. Also Thanks to @TLATER .
Here’s the solution summary:

Since HM manages the configs, it’ll clash with existing operations. It’s usually not overwriten by default, coz we may have some important data there. So it’s best to check things out and manually delete the old config.
Or otherwise, personally the better way I felt is (since I now understand how HM works).
In the configuration.nix in the homemanager module’s option .
Add this:

home-manager.backupFileExtension = "backup";
(Replace backup with bak or whatever u prefer).

This way in future if u migrate programs, HM will work properly discarding old configs.

1 Like

But the pain I feel is not all applications are pure manual-config friendly.
Eg: gh
It can’t save the login credentials/token because it’s immutable from nix store. I’ll think of other ways later.

Unless already a backup exists… HM will not overwrite nor backup backups, activation will again fail.

1 Like

gh auth is indeed a pain, I usually rm the HM managed config, allow gh auth to write out the config as well as the auth file, and then I delete the generated auth file and let HM take over again.

From then on gh works fine and updates the tokens in the auth file just fine.

That will only work once. The next time you attempt to override an existing configuration (which may be created by another application), home-manager will fail to activate again. If you don’t keep an eye out for this, you’ll end up with a home-manager config that stops applying correctly again.

I’d really recommend actually figuring out what file is blocking this and solving the problem, rather than creating backup files.

Generally the idea is that you don’t hand-edit stuff, it’s kind of the entire point of using home-manager. If you want to do imperative config, consider not using home-manager for those applications.

2 Likes

U got me wrong, by manual config I meant mutable reflection in the config. But since config files by HM are just symlinks from nix store. Not all applications can update the config by themselves.

Yes, most of the time, this is what we want. Config remains how we set them, not how some misclicked button thinks they should be…

1 Like