I’m using `deploy-rs’ to roll out configuration changes at a system level (/etc/nixos/configuration.nix) and works great.
I’m also trying to use it to roll out home-manager configs. I do my deploy #.my-system.some-user and all appears to go swimmingly, except the home.nix on the remote is not actually modified or replaced.
in my flakes outputs I have:
homeConfigurations.botman = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
modules = [ ./home.nix ]; # Home Manager config for botman
};
The file ~/.config/home-manager/home.nix is never modified and a manual home-manager switch doesn’t apply anything either. Is anyone able to help me understand what is going on ?
Apologies for answering a question with a question, but is there a particular reason you don’t use the home-manager NixOS module? Most cases of home-manager-on-NixOS really should be doing that, and it’d definitely sidestep this issue, whatever the actual problem is.
I’m hardly a nix/deploy-rs/h-m expert, but I wouldn’t expect it to overwrite a home.nix on the target, any more than I would for a configuration.nix? Surely it evaluates, builds and activates the configuration itself, so only the “results” end up the target?
Running home-manager switch on the target will presumably evaluate, build and activate the existing home.nix if you haven’t replaced it, the results of which would then supercede the config you’d pushed with deploy-rs?
Hey thanks srd24… you’re probably on to something that I’ve just failed to apprehend. I think I’m confused the about what I expect it to do.
So, deploy-rs should take configurations I’ve made to a reference home.nix locally and build/apply (i.e. copy to and activate) the results on the remote? so, if thats happening, what should I expect to see? if this is done for user fred, then sshing, or (as say root) sudo -iu fred should now experience the benefits of those results, as if the change had been made on the machine by fred and he had done home manager switch. Am I at least correct to that point?
I see your point about expecting it to modify ./config/home-manager/config.nix, I just don’t understand how to ‘get’ the benefiits of the result applied by deploy-rs ??
OK! This is put my on the right track, thanks Srd424… it has been working all along, my ‘test’ to see if it was working just was not a suitable test and the error was in actually in the config i was applying.
Not exactly. You have home-manager installed on top of NixOS, completely detached from each other. You could make NixOS deploy home-manager, so that you only need to (effectively) nixos-rebuild to apply both home-manager and your NixOS config. They can integrate that way, and not integrating them is indicative of misunderstanding home-manager IMO.
There are valid use cases for what you’re doing, but I check whenever I see a newbie asking about home-manager/NixOS integration issues, because you could save yourself a lot of headaches if you aren’t intentionally splitting them apart.
Well, that depends on what your configuration change effected. If it’s just some package updates, maybe it won’t be immediately noticeable. deploy-rs will still contact the remote basically to check if anything needs to change, too, so in either case it will do something, it might just not have a noticeable effect.
Ok, so what i understand you’re saying, is, if home-managers ‘config’ is ‘managed’ all within configuration.nix, so from a deploy-rs view, I’m only deploying ‘the box’ and home manager is ‘switched’ when appropriate. So, in my scenario, where users don’t need to manage their own environments with their own proclivities, this could make sense.
The only reason this box (or really class of boxes) is using home manager, or i even have a separate user is, I’m runing a set of podman containers which I don’t want ‘interupted’ everytime I update something on the box vi config.nix, so I figured separating them out to be controlled by a separate ‘user’ with their own discrete config separately applied to the box config might allow that.
So, if i just move my hm config into configure.nix, and I apply system level changes will there be interruptions as the new builds are activated do you know?
re ‘I just dont understand how to get the benefits’… I was getting them (for example package changes/updates/additions), but I was verifying my changes using an environment variable set in hm sessionvariables, which wasn’t being loaded in to the shells. When I addressed that, all was well.
There should not be. As long as your podman containers do not depend on things in the home-manager closure, their closures will not be updated and therefore the activation script won’t pick up any changes which would make it restart those units.
You can also modify the systemd units of the podman containers and set the various restart* and reload* options to prevent NixOS from touching them unnecessarily - you’d have to explicitly add home-manager config to those options to make your home-manager config affect the podman containers, though.
And that’s assuming you use virtualisation.oci-containers.containers to start those podman containers. If not, and you’re just running normal system (i.e., not as your user) podman containers with the podman command, your home-manager configuration really should not affect them.
If you run user podman containers you could touch them if you tried, admittedly, but iirc podman containers use systemd user units for this, and you’d have to explicitly override those. It’d be quite hard to do that on accident.
With that said, if you have a “thin” user on that host you should consider whether you even need home-manager. For just simple vi config and such NixOS actually has pretty serviceable options.
thanks for all your thoughts, and taking time to explain this to me. I’ve moved all this into configure.nix and that’s allowed me to simply things significantly.