I’m curious, is anyone using chezmoi on NixOS? I realize home-manager is far more popular within the Nix community, but for whatever reason I’ve been hesitant to embrace it. I’m reading about chezmoi, and strongly considering giving it a try.
chezmoi is “just” a dotfile manager, whereas hm is a tool for configuring your entire environment. If you are already on nixos, which use-cases are better served by chezmoi (or other dotfile managers) than hm?
I still use a dotfile manager (but not chezmoi) on NixOS and macOS (I have been storing my configs in the dotfile repo, though I think I’ll break the purest ~config part of that out into a flake when I have energy to convert it.
I still use a dotfile manager (but not chezmoi) on NixOS and macOS
There are a few applications where the configuration doesn’t lend itself to being statically defined and read-only. For that I just have a git repository and use stow/make to symlink those into place or use a custom hm module that merges the settings I care about into the correct file.
I guess maybe the stow/make combination qualifies as a basic dotfile manager…
But what OP was talking about was not using hm at all and use a dotfile manager instead. I’m still super curious as to what use cases are better addressed by that.
If my config files are older than the NixOS module system per se, and substantial parts of them might outlive it, but I want a bit of templating support — it is obviously more natural to put it into something like chezmoi than to figure out how home-manager calls things in this decade.
(I just have my own templating scripts for the few cases where symlinks to repositories and includes from a FUSE access point to password manager are not enough)
well, I dont think there are a “few” applications where the configuration needs to be RW, but a lot of them, especially GUI ones.
there is also the issue of not wanting to keep everything in the store … where its public and RO. And I am not talking about passwords and secrets, but also things like bookmarks, etc.
There is also impermanence , which even has a “stow like mode”.
Home Manager and Impermanence should cover the functionality of a dotfiles manager.
My reservations about home-manager are somewhat related to indecision. Each time I start looking into it, I run into questions like:
- do I want a standalone installation, or a nixos module?
- should I use a flake?
- should I convert my entire nixos config to a flake first?
I keep going back to my hacky home-grown scripts (which use Stow under the hood).
When I learned about chezmoi, I was struck by some similarities with the pass
password manager, in terms of its interface and some of its Git underpinnings. I’m not sure it handles any particular use-cases better than home-manager, but it certainly seems better than my current Stow-based solution and it’s something I could migrate to pretty easily.
I made the transition to HM slowly over time. I’d used dotbot for a few years. I started by creating a standalone setup with a flake, then created a home manager activation script that would call dotbot for me. After that I used home manager to do all my switching, though could still technically run dotbot by hand (or chezmoi).
Over time I slowly converted more and more things to be managed through nix. Eventually I had dotbot pared down to just those apps I wanted to keep symlinking for whatever reason. Finally I converted all those to use mkOutOfStoreSymlink so that I could eliminate dotbot completely.
I recently switched to Nixos and don’t know yet HM so much. I use chezmoi to manage .dotfiles and some external tools (binaries from github, source repos), mainly also cause I also use systems which are not NIxos.
I actually also wanted to keep using chezmoi as it is perfectly fine to deploy also on other platforms where I dont use Nix etc.
Therefore I am looking out for a solutiont to incorporate chezmoi init https://repo-url/main
and chezmoi apply
.
Is there anyone experienced how that should be integrated into HM.
I do not want right now to switch everything to HM, but kind of just simply interface chezmoi…
Any thought?
Think this is still a valid question. My usecase would be to use chezmoi with bitwarden to manage passwords and keys across platforms, not just Nix and I’d like to use a single solution for that
I do this now with chezmoi and age and encrypt files directly into the dotfiles repo, bitwarden I only use for working not to fill in passwords in my config files. But maybe you are right with bitwarden it would be better, but
chezmoi apply must be used with —exclude encrypted because during home activation (when doing direct apply) its not so good too rely on internet access and prompts to enter passphrase for age e.g. I think bitwarden contains to many passwords I do not want to expose in the switch process of nixos etc, so an age approach with certain stuff is probably fine. Not sure what you have in mind.
I understand, but I’m running a vaultwarden instance where I’m planning to create a user with just the passwords and secrets for the nix setup. With the vaultwarden container accessible only through a certein set of tailscale clients I think I’m fairly safe from an who can access perspective. (The container has no other outside access, just tailscale, and to get to it you have to go through authentik with 2fa.)
ahh sounds cool, can you share the nixos config? how does a switch deploy the configs, how can that be non-interactiv? does that work or how is your workflow?
once I’ve put it all together I’ll share a link, still working out the kinks atm (like how to remotely start the config)
Please do share you work-in-progress, I’d like to learn how other people think in NixOS, especially with chezmoi.
Remember, perfect is the enemy of good.
Here’s mine. It’s home-manager, not NixOS, but the concept is similar: universe/home-manager/profile/minimal.nix at 9c9246c137ab1528e534399e859773a243355478 - SapphicCode/universe - Forgejo: Beyond coding. We forge.
Though, if I was writing this into a NixOS config, I would suggest making this a systemd unit with an After = ["network-online.target"];
instead of an activationScript which might run at a time without networking.