Transitioned from gnu stow to nix/home-manager and haven't looked back.
The great part about that setup is my configuration contains not just my dotfiles, but also the installation of the programs themselves.
I don't use the "nix" way of configuration though, I instead have home manager symlink everthing for me. Then I can bail on nix anytime and not have to translate all my files back to yaml.
Glad programs like the above exist though for those who don't want to sink time into nix but want to reasonably track configuration.
I did almost the same, but I am converting things as slowly/lazily as possible.
One thing that helped me tremendously migrating the configuration bits was to leave "scratchpads" that I could tweak quickly without a full rebuild cycle:
programs.kitty.extraConfig = ''
include ${config.xdg.configHome}/kitty/temporary.conf
'';
Then my ~/.config/kitty looks like this:
~/.config/kitty $> ls
87 Dec 13 11:39 kitty.conf -> /nix/store/....-home-manager-files/.config/kitty/kitty.conf
381 Dec 13 11:42 temporary.conf
I’m fully invested in Nix/Home Manager, and I use YADM to manage the nix files and other random stuff that isn’t in Home Manager yet or doesn’t fit.
IMO it’s a good fit to use them together. YADM lets me do things like easily setting per-host configurations, encrypting secret files, etc.
My new host setup is to use YADM to pull my dot files, then install nix and run home-manager to install everything else. YADM even supports bootstrapping to automate that for me
Without more information, that sounds like extra complexity. You can easily do per-host configurations using home-manager. Actually, I consider that one of the perks of the nix based setup, so I'm not sure why I'd want another tool for that.
Gnu guix has a system that does this as well. I just started using it and have had use for it already: replicating my home environment on another computer was flawless.
Copied one dir over, ran guix home reconfigure and after everything installed, the environment was... Almost the same. I just need to write an integration that installs flatpaks since some apps are only available there.
I am very difficult to please when it comes to dotfile managers. I tried all of them and I'm quite fond of rcm[0]. It's been a few years so it's hard for me to remember exactly what it was but I think both chezmoi and yadm involved some kind of step to "apply" changes but I just want things symlinked into a dotfiles repo that I have a cron job which basically does `git ci -a && git push` to synchronize changes.
That said, I don't think rcm should be anyone's first choice. I'd check it out if nothing else seems to work for you. From what I hear, chezmoi seems to be most people's favorite so I'd start there. I don't know a single other person that uses rcm.
Does this program allow linking the same file to different locations on MacOS vs Linux? I have a few config files like the vscode settings.json that end up in different paths but have the same content. (I see it allows for files that are OS specific but not clear if there is a way to keep them in sync if they are the same, but just need different paths)
I use stow at the moment and it is almost perfect but I don't believe it can do that without multiple symlinks or something messy. Didn't like home manager and other dotfiles solutions seemed too bloated for my case
The workflow that you show in your repository is really not that different from Chezmoi. If you configure a post-add hook in Chezmoi (https://www.chezmoi.io/reference/configuration-file/hooks/), you can do `chezmoi add ~/.config/whatever/whatever.conf` and have the file auto-added to the Chezomi git repo + push it to some remote if you'd like.
I was also not thrilled about the idea of shipping an encrypted blob of important secrets around. I want my dotfiles to be public, so it's much nicer when the tool I use for managing my dotfiles natively integrates with 1password. Much of the templating functionality that I use from chezmoi is specifically for pulling stuff out of 1password.
Finally, the yadm "alternate files" functionality is nice, but I didn't really care about alternates for different OSes or hostnames or whatever. I wanted some configuration for my work machine(s) and some configuration for my personal machine(s) - that's it. That's the only distinction I care about. Chezmoi made it easy to prompt for the type of machine + change the things that get configured accordingly when bootstrapping a new machine (https://github.com/cweagans/dotfiles/blob/main/.chezmoi.toml...).
Did chezmoi make it easy to edit and then add fileswith changes?i hated always having to chezmoi this and that rather than doing what i want then runn*ng yadm -u to pick up all the changes in my tracked files
Pretty sure there are a couple of aliases that you could create to get you the workflow you want. I just edit my files on disk, chezmoi add file, then periodically fit commit and push them. You could create a post add hook to automatically git add/commit/push + I’m reasonably sure there’s a chezmoi command to list all tracked files, so you could iterate through all of them and do whatever you want with them.
My only complaint about yadm is that I've never managed to get its use of git submodules to work reliably. Sometimes I think I get it working, then notice that the submodule lags behind the remote git repo, and no amount of prodding at it gets it to go to the (real) head.
submodules may or may not be annoying to use in a particular use case, but they work perfectly (in that they do what they do, not necessarily what you want/expect)
from your comment, it sounds like you might not have the exact mental model of how they are expected to work?
> then notice that the submodule lags behind the remote git repo
the version of the submodule is staked to an exact commit hash in the main (outer) git repo. the use case is that the submodule should not "float" or change - if you check out a particular commit in the main repo, it will always point to this same submodule commit
if you change the main repo branch, etc. you additionally have to ask to sync up the submodule for that new commit. i use:
git submodule update --init
instead, if you want to update the submodule to a new commit (e.g. to latest master branch), you have to enter the submodule, checkout the branch and pull. then in the main repo, you will add the submodule and commit it to link to the new submodule commit.
so that can be annoying of course. but i find it works extremely well for submodules that are dependencies that you want staked to an exact version.
Transitioned from gnu stow to nix/home-manager and haven't looked back.
The great part about that setup is my configuration contains not just my dotfiles, but also the installation of the programs themselves.
I don't use the "nix" way of configuration though, I instead have home manager symlink everthing for me. Then I can bail on nix anytime and not have to translate all my files back to yaml.
Glad programs like the above exist though for those who don't want to sink time into nix but want to reasonably track configuration.
I did almost the same, but I am converting things as slowly/lazily as possible.
One thing that helped me tremendously migrating the configuration bits was to leave "scratchpads" that I could tweak quickly without a full rebuild cycle:
Then my ~/.config/kitty looks like this:I’m fully invested in Nix/Home Manager, and I use YADM to manage the nix files and other random stuff that isn’t in Home Manager yet or doesn’t fit.
IMO it’s a good fit to use them together. YADM lets me do things like easily setting per-host configurations, encrypting secret files, etc.
My new host setup is to use YADM to pull my dot files, then install nix and run home-manager to install everything else. YADM even supports bootstrapping to automate that for me
I wrote a little tool that symlinks stuff from your git repo into $HOME.
https://github.com/Lillecarl/nixos/blob/master/users/lilleca... https://github.com/Lillecarl/nixos/blob/master/scripts/uglin...
There's something called mkOutOfStoreSymlink that does this natively, but it makes a symlinks from $HOME -> store -> git repo which annoyed me a bit.
For me getting my home environment up and running is just "FLAKE=$PWD nix run nixpkgs#home-manager -- --flake $FLAKE - - impure"
It's nice to not use "Real home manager" for some kinds of configurations since Nix is pretty slow.
Without more information, that sounds like extra complexity. You can easily do per-host configurations using home-manager. Actually, I consider that one of the perks of the nix based setup, so I'm not sure why I'd want another tool for that.
Gnu guix has a system that does this as well. I just started using it and have had use for it already: replicating my home environment on another computer was flawless.
Copied one dir over, ran guix home reconfigure and after everything installed, the environment was... Almost the same. I just need to write an integration that installs flatpaks since some apps are only available there.
Doesn’t that limit you to deploy dot files to nix available system only? That’s the primary reason I don’t use home manager.
I am very difficult to please when it comes to dotfile managers. I tried all of them and I'm quite fond of rcm[0]. It's been a few years so it's hard for me to remember exactly what it was but I think both chezmoi and yadm involved some kind of step to "apply" changes but I just want things symlinked into a dotfiles repo that I have a cron job which basically does `git ci -a && git push` to synchronize changes.
That said, I don't think rcm should be anyone's first choice. I'd check it out if nothing else seems to work for you. From what I hear, chezmoi seems to be most people's favorite so I'd start there. I don't know a single other person that uses rcm.
[0] https://thoughtbot.github.io/rcm/rcm.7.html
Does this program allow linking the same file to different locations on MacOS vs Linux? I have a few config files like the vscode settings.json that end up in different paths but have the same content. (I see it allows for files that are OS specific but not clear if there is a way to keep them in sync if they are the same, but just need different paths)
I use stow at the moment and it is almost perfect but I don't believe it can do that without multiple symlinks or something messy. Didn't like home manager and other dotfiles solutions seemed too bloated for my case
Yes, it does. https://yadm.io/docs/alternates#
I used yadm for a while. I switched to Chezmoi (https://www.chezmoi.io) though. Same ideas, but much better execution IMO.
I'm surprised by this because I find the chezmoi workflow very annoying, to the extent that I wrote my own thing (see my other comment).
Where did you find yadm fall short?
The workflow that you show in your repository is really not that different from Chezmoi. If you configure a post-add hook in Chezmoi (https://www.chezmoi.io/reference/configuration-file/hooks/), you can do `chezmoi add ~/.config/whatever/whatever.conf` and have the file auto-added to the Chezomi git repo + push it to some remote if you'd like.
yadm made it difficult for me to take specific actions when a file changed. For example, I configure a lot of macOS settings in my dotfiles (https://github.com/cweagans/dotfiles/tree/main/dot_config/ma...). When any of the JSONC files change, I need to run a script to actually apply them (https://github.com/cweagans/dotfiles/blob/main/.chezmoiscrip...), but I don't want to do that unconditionally. Chezmoi tracks that state for me and only runs the script when needed. Ditto with the macOS config profile (https://github.com/cweagans/dotfiles/blob/main/dot_config/ma... and https://github.com/cweagans/dotfiles/blob/main/.chezmoiscrip... respectively).
I was also not thrilled about the idea of shipping an encrypted blob of important secrets around. I want my dotfiles to be public, so it's much nicer when the tool I use for managing my dotfiles natively integrates with 1password. Much of the templating functionality that I use from chezmoi is specifically for pulling stuff out of 1password.
Finally, the yadm "alternate files" functionality is nice, but I didn't really care about alternates for different OSes or hostnames or whatever. I wanted some configuration for my work machine(s) and some configuration for my personal machine(s) - that's it. That's the only distinction I care about. Chezmoi made it easy to prompt for the type of machine + change the things that get configured accordingly when bootstrapping a new machine (https://github.com/cweagans/dotfiles/blob/main/.chezmoi.toml...).
Did chezmoi make it easy to edit and then add fileswith changes?i hated always having to chezmoi this and that rather than doing what i want then runn*ng yadm -u to pick up all the changes in my tracked files
Pretty sure there are a couple of aliases that you could create to get you the workflow you want. I just edit my files on disk, chezmoi add file, then periodically fit commit and push them. You could create a post add hook to automatically git add/commit/push + I’m reasonably sure there’s a chezmoi command to list all tracked files, so you could iterate through all of them and do whatever you want with them.
Cool, I'm going to give this a try.
I got frustrated with the chezmoi workflow and had Claude write something similar for me the other day.
https://github.com/snth/dot
It's just a simple bash script that acts as a wrapper around git and copies tracked files to a dotfiles directory and back.
My only complaint about yadm is that I've never managed to get its use of git submodules to work reliably. Sometimes I think I get it working, then notice that the submodule lags behind the remote git repo, and no amount of prodding at it gets it to go to the (real) head.
submodules may or may not be annoying to use in a particular use case, but they work perfectly (in that they do what they do, not necessarily what you want/expect)
from your comment, it sounds like you might not have the exact mental model of how they are expected to work?
> then notice that the submodule lags behind the remote git repo
the version of the submodule is staked to an exact commit hash in the main (outer) git repo. the use case is that the submodule should not "float" or change - if you check out a particular commit in the main repo, it will always point to this same submodule commit
if you change the main repo branch, etc. you additionally have to ask to sync up the submodule for that new commit. i use:
instead, if you want to update the submodule to a new commit (e.g. to latest master branch), you have to enter the submodule, checkout the branch and pull. then in the main repo, you will add the submodule and commit it to link to the new submodule commit.so that can be annoying of course. but i find it works extremely well for submodules that are dependencies that you want staked to an exact version.
Some more dotfiles resources:
https://dotfiles.github.io/ https://vcs-home.branchable.com/
I'm satisfied with Ansible for this use case
Can’t we stop naming things with “Yet Another,” yet?
Yet Another Considered Harmful Is All You Need
Yet Another Considered Harmful
YAQTSNT
“Yet another question to say no to”
Yet Another Complain About This?