Originally I installed hm as a module because I wanted to have all of my nix configs in one place but as I started actually using it seems a little bit silly having to run full system rebuild just because I want to change a shell alias.
Is it reasonable to convert to stand-alone home managers and what are the potential pitfalls I should be aware of when doing so?
Yeah, it’s quite trivial, just move the configuration to a separate home.nix, rebuild, and then install home-manager according to upstream instructions.
Your global pkgs will not be synced with the home-manager pkgs, so you’ll need to be careful to derive both from the same input and apply the same config to both.
That said, having to remember to run both in lockstep will drive you up the wall. Rebuilding your system config just to change a shell alias really isn’t so bad, remember nix is lazy, so if there are no other changes this won’t really cause much additional overhead. home-manager’s activation script is significantly slower IME, and both have to evaluate a significant amount of modules, so this won’t speed up switching significantly either.
If you often have system changes you don’t actually want to activate yet, I’d suggest learning git a bit better, stashes, commits and branches, coupled with good understanding of the rebase functionality, are a much better solution to that problem.
If you understand git but don’t use it because you find git cumbersome, invest in finding and learning how to use a good git porcelain. It’ll pay back that effort manyfold every day for the rest of your software life.
I am interested in your answer because I also consider switching to standalone.
“having to remember to run both in lockstep” ? I would imagine 99% of the time, either I change some $HOME config or I change some system package/setup . But having not used it I may miss something…
Rebuilding the system to update hyprland keyboard shortcuts is really awful.
A good 90% of the time I at least change both. Most changes to config are updates in the long term, and those affect both.
Again, sure, you’re building the “whole” system, but this hardly changes evaluation time. Whether you build just home-manager or NixOS and home-manager, you have to evaluate nixpkgs anyway since both depend on it.
So the only difference is that in one case you evaluate (and then don’t do anything with) the NixOS module system, and in the other you don’t. It may even result in overall faster evaluation in the cases where you do update both (which is, again, quite common), since you can reuse one nixpkgs instance. The difference in evaluation time probably is not very significant in general.
Remember that nix isn’t imperative, there’s no effect to evaluating the system if its config did not change.
The only perceivable difference, besides evaluation time, is that your generation switches are cleaner if you do them together, since both the home-manager and NixOS packages get updated in lockstep. This means that changing the generation on your boot selection screen will succesfully roll back your system to what you selected; if you split the configurations, things deployed only with home-manager will stay broken, and potentially break further if they don’t align with host services.
I can see wanting to split the configurations if you have a multi-user system, since it doesn’t really make sense to change someone else’s configuration when you want to roll back a system update or such. But for the single-enduser systems people typically have I don’t think there really is a sensible use case for standalone home-manager.
Thanks for input.
Maybe I could consider an alternative then- when I have to perform some test on my ~/.config, I could try to temporarilly bypass HM, find the settings which works, then put the settings I like in HM.
So I keep HM as a integrated module but I use a temp workaround when using the nix way is tedious for back & forth inside a given config…
Again thanks 
That’s practically how I do it for emacs, just with (eval-region) on the config I’m writing so it’s less tedious.
Most applications will need some command to pick up the new config anyway; you can just make sure that those commands are run as part of the activation script if that’s what’s annoying you.
1 Like