6 ms·

Migrating from GNU Stow to Chezmoi

141 points by speckx 5mo ago

lucideer 5mo ago
I must've tried to set up stow five or six times over the years, in between various hand rolled custom setups. I can't put my finger on why but I set up chez moi & it's been my setup since, much longer than any previous solution. Chez moi is definitely not without its rough edges but it seems to have gotten the subtle essentials right enough for adhd me to not have abandoned it yet.
- guhcampos 5mo ago
  I used stow for a long time, then tried Ansible, but eventually settled into good old Make. `make dotfiles` just creates a bunch of symlinks, takes 5 minutes, all good and happy. Everything is modular, declarative, simple. Never looked back.
  - lucideer 5mo ago
    I think this is likely a part of the friction for a lot of people - symlinks. There's roughly two main ways to manage dotfiles: - symlink - copy & sync The 2nd (what chez moi does) is pretty hard to get right from a UX perspective.
- sureglymop 5mo ago
  Same here. I would say chezmoi has almost a bit too many features. If one is into yak shaving there is a lot to explore. It's only a negative for me because I forget half of them everytime I read the docs. But I can hardly blame it for that, it's great!
- linhns 5mo ago
  I nearly jumped from GNU Stow, but settled when I find the —-no-folding flag
drdexebtjl 5mo ago
I had similar problems with GNU Stow, but switched to Nix and Home Manager instead. I think Chezmoi's templates and file naming conventions don't click for me, but it's nice to see a good variety in this problem space.
- colordrops 5mo ago
  People shy from Nix because of supposed complexity but it really is the only real solution to this sort of problem. It's not really that much more difficult to learn, and in fact if you are willing, AI works really well generating nix config.
  - chungy 5mo ago
    Guix solves the same problem in similar ways, though it uses Scheme as its configuration language.
    - drdexebtjl 5mo ago
      Sadly it doesn't work on macOS, unlike Nix.
      - pkulak 5mo ago
        Or hardware.
        sham1 5mo ago
        It absolutely works with hardware. And it's not that difficult to add channels for extra software like a tainted Linux kernel. And in return one gets a saner programming language than the Nix language.
  - drdexebtjl 5mo ago
    It took me a single afternoon to learn the basics and start using it. Contrary to what I initially thought, I didn't have to migrate all of my dotfiles at once. Then over the next couple of days, Codex migrated everything else for me. One major benefit for me is that I no longer need to have once-in-a-while tools installed, because I can always spin up a temporary shell with `nix-shell -p packageName`. This significantly decreased the amount of software I have in my environment. This works great with agentic coding. Agent wants to run `ripgrep`, but you don't have it? Tell it to run `nix run nixpkgs#ripgrep` instead. But the biggest benefit is that now that you know Nix! So you can start using it to create reproducible development environments and uninstall mise, asdf, nvm, pyenv, etc. You can spin up reproducible servers running NixOS and never touch Ansible again. You can even install it in your router. Or you can do none of that and continue just using it for your dotfiles. It plays nice with other tools.
rochak 5mo ago
I've been using [yadm](https://yadm.io/ https://yadm.io/) instead which works really well!
- laurentlbm 5mo ago
  I've been happy with yadm for few years now. I had tried chezmoi, but preferred yadm. I don't remember my exact reasons though...
  - markstos 5mo ago
    I looked at Stow and Chezmoi and also have stuck with YADM. The exact reason is that YADM is so simple and intuitive because it's basically Git-for-dotfiles with so little to learn. Yet it also manages to support alternate and template files.
  - duskdozer 5mo ago
    I looked around at a bunch but settled on yadm for basically just using a normal git workflow. I wanted to just edit the files directly, know what it's doing, and not change how I worked. I really dislike the `<tool> edit/run/<standard command>` UI pattern that's fairly common now.
- jdxcode 5mo ago
  I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm https://github.com/thoughtbot/rcm
spudlyo 5mo ago
It's great to manage your dotfiles, but I took it a step farther. I rebuilt the minimal Linux desktop environment of my dreams (startx, xinit, i3, i3status etc) with Ansible. It begins from a vanilla Ubuntu server 24.04.4 install. I bootstrapped it using a KVM + spice setup (using a spare physical SSD rather than a virtual one) and iterating over and over again until I finally got everything mostly working. I then booted off that physical disk, and kept iterating until everything was perfect. I've since adapted the setup to work on virtual aarch64 on macOS. I just recently tuned it to work on a crappy old Haswell Dell laptop, now properly detecting and configuring hardware vaapi capabilities, backlight, battery, trackpad, trackpoint, etc. Pretty snazzy, watching YouTube in Firefox on a 13 year old laptop with hardware h264 decode and everything tuned exactly to my liking.
- anuramat 5mo ago
  don't want to be that guy, but have you tried nix?
  - spudlyo 5mo ago
    I tried GUIX a few times, but ultimately I couldn't quite get it working exactly the way I wanted it to work. I also didn't like the ugly filesystem layout that the store requires. I may get over it and revisit at some point. It will be a lot of work, but on the plus side I'll have a reason to learn scheme.
- trallnag 5mo ago
  I did that too across three devices and it turned out to be a huge time sink similar to tinkering with a personal server
mmh0000 5mo ago
I’ve always managed this problem in a different way. I don’t know if my way is better, but it works really well for me. I treat my powerful desktop computer as my main machine. Then I have a bunch of laptops. Then I just rsync my entire home directory out to all the laptops. From there. The rule is quite simple. Any file created on a laptop are considered ephemeral. If I create data that I have to keep. It gets rsynced back the other direction to the main machine. This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process
- shevy-java 5mo ago
  Interesting. I go about this differently. I have one master setting and from there ruby just autogenerates anything I'd ever need on other computers. If ruby is unavailable then I just copy the generated files. But I only edit the master setting to enable what I need. > This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process I feel in a similar way but not with shell scripts. Ruby autogenerates them if I need them too. Ruby is my ultimate glue to hold together everything.
- deleted 5mo ago
  [deleted]
- cwel 5mo ago
  > rsync my entire home directory out to all the laptops Interesting approach. Whether it could be considered 'better' or not depends on what your 'handful of shell scripts' do.
- mixmastamyk 5mo ago
  I feel like git or other vcs would be a bit safer. I could see myself syncing the wrong way.
arrakeen 5mo ago
i feel like using GNU stow to manage your dotfiles has always been a hack.. has it ever been a supported usecase? stow is an indispensable tool for me to manage /usr/local for manually installed software. my workflow goes: ./configure --prefix=/usr/local/stow/myapp make && make install stow myapp now, myapp and all its supporting files are in the right place in /usr/local. if i want to "uninstall", i just run stow -D myapp
- WCSTombs 5mo ago
  I like to use environment modules [1] (or lmod [2]) for that purpose. You can make each manually built software package available or not on a per-shell-session basis, just by running module load myapp or module unload myapp in the shell where you want it (or don't). The small downside is that it only works with software that actually uses the standard environment variables like PATH, CPATH, etc. for their intended purposes rather than hardcoding filesystem paths, but in my experience it's rare to find something that doesn't. Also, you have to write a modulefile for each package, but that's not a big deal. [1]: https://modules.readthedocs.io/en/latest/ https://modules.readthedocs.io/en/latest/ [2]: https://lmod.readthedocs.io/en/latest/ https://lmod.readthedocs.io/en/latest/
shevy-java 5mo ago
I hate . dirs. In fact, I hate them so much that I don't use them. My configuration lives primarily in .yml files. These are kept super-simple. When need be and another format is required, ruby autogenerates these for me. For instance, all my bash aliases are kept in .yml files which then get turned into bash rc files or any other target format for other shells. Same for most of my other configuration too - not always .yml but usually some text file. I never understood the neet for .foobar directories or files. They just hide a system that is intrinsically ugly and needlessly complicated.
- RunningDroid 5mo ago
  You might like xdg-ninja‡ then, it tells you what program put which item in your $HOME and how to move it to ~/.config or $XDG_CONFIG_HOME. ‡: https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja
- chuckadams 5mo ago
  Found the Kubernetes guy ;)
QwenGlazer9000 5mo ago
Chezmoi strikes a nice balance between the overkill of home-manager while still being more powerful than simpler solutions. Yadm is another alternative, the main thing I don't like about it though is that I'm not a fan of cross OS dotfiles. Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit. As powerful as the templating in chezmoi is, I think it should be considered a last resort and only used for simple files. They break your editor features like highlighting.
- cwel 5mo ago
  > Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit https://www.chezmoi.io/reference/special-files/chezmoiignore/ https://www.chezmoi.io/reference/special-files/chezmoiignore... > They break your editor features like highlighting https://github.com/alker0/chezmoi.vim https://github.com/alker0/chezmoi.vim
pkulak 5mo ago
Once you hit the Chezmoi stage, you're only about 6 months from Nix and Home Manager. I mean, why climb _almost_ to the top of a mountain and then just sit down?
- halostatue 5mo ago
  I've bounced off Nix every time I tried it, before I even started trying something like Home Manager. I've been using (and contributing to) chezmoi for ~6 years now. Given that it has first-class integration with secrets managers, I suspect that it does things that Home Manager can't.
  - linsomniac 5mo ago
    >I've bounced off Nix every time I tried it, before I even started trying something like Home Manager. I did too. Until I tried configuring it with Claude Code. I'll give you my money back guarantee on it.
    - bronson 5mo ago
      Vibed infrastructure? That sounds like it undoes a lot of Nix's advantages.
  - redog 5mo ago
    > it has first-class integration with secrets managers Meow?
    - halostatue 5mo ago
      No slight involved. The chezmoi integration with 1Password is excellent; for those who prefer Bitwarden, it supports both the default CLI (which has some inexcusable behaviours for a security product, IMO) and `rbw` (which is infinitely better than the default CLI). It supports `pass`, `gopass`, `passage`, AWS Secrets Manager, KeePass, and several other approaches. It was the work of a couple of minutes to enable a secret for a Claude Code API token to be mounted in a VM where I'm running Claude for a project where the value is pulled from 1Password and I can regenerate it and reapply without fear. If one doesn't have to worry about secrets in one's dotfiles, I'm sure that other dotfile managers including Nix with Home Manager will suffice. I do, so they won't.
vsviridov 5mo ago
Switched to Chezmoi from random assortment of manually authored scripts. The workflow takes some getting used to, because I constantly edit the actual files without calling `chezmoi edit` first, and have to merge. I like that when combined with `mise` (https://mise.jdx.dev https://mise.jdx.dev) I can roll out a new computer in 2-3 commands and have my entire environment configured the way I like, with neovim and all the plugins and language servers.
- deleted 5mo ago
  [deleted]
- LVB 5mo ago
  I never did get used to the Chezmoi workflow. `chezmoi edit` never became muscle memory, and I was constant finding myself resolving diffs and what not.
  - vsviridov 5mo ago
    BeyondCompare 2-way merge usually resolves everything automatically, and it's set up as the default mergetool for me, so it's only a couple of clicks... But yeah, takes some muscle memory.
groos 5mo ago
~50 years of distributed systems research and this is a problem we still have to deal with today. Sad!
jdxcode 5mo ago
It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html https://mise.jdx.dev/bootstrap.html It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd. EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend checking it out.
- halostatue 5mo ago
  Are there plans to support MacPorts as a packaging system? I only use Homebrew for casks, because I find it unreliable for core development tools.
  - jdxcode 5mo ago
    Haven't looked into it but agents are so good at this I bet it'll be trivial to add
- 0cf8612b2e1e 5mo ago
  I am quite intrigued. With the sorry state of security, I am doing everything in VMs and have been trying to settle on the best way to setup a new machine. The process is so clunky that I end up defaulting to bigger instances than I should (more pets than cattle). Being able to centralize this config is far more attractive than having a separate Ansible or pyinfra process. Edit: The docs on this are very encouraging! However, it is not clear- what is experimental? Anything notably buggy or churning? Any far off features you hope to implement some day?
  - throawayonthe 5mo ago
    i would reach for atomic fedora personally, maybe with bluebuild
    - 0cf8612b2e1e 5mo ago
      That still feels like more external tooling, plus letting the distro make my packaging decisions. I am already using mise, so this is an almost free boon without more complexity.
cue_the_strings 5mo ago
[dead]
sgarland 5mo ago
I learned about Stow after I found out about Chezmoi, and felt like Chezmoi was the better fit for me. I make heavy use of templating to keep work / personal aliases and functions separate, and could not be happier with the outcome.
- wyclif 5mo ago
  It is definitely a better fit because Stow was never intended to function as a manager for dotfiles under version control.
blop 5mo ago
I use syncthing to automatically sync my dotfiles git directory across PC/laptops, and stow to manually update symlinks when I add a new dotfile (the content of existing dotfiles is synced by syncthing already) That way I don't have to remember to commit+push+pull changes to existing dotfiles (like bashrc or vimrc which I edit often) to sync them to other machines, it happens automatically in almost real time as soon as the file is saved on one of my machines (syncthing uses inotify to detect changes on monitored directories)
- c-hendricks 5mo ago
  This is what I did too. My dotfiles used a custom install process that didn't really handle ~/.config very well, so I switched to stow, and then added syncthing because the push + pull dance got too annoying. Really happy with it.
Ferret7446 5mo ago
I've never really understood why people get so fancy with their setups when you can just plop a git repo into your home directory. I suspect it has to do with people being unfamiliar with git.
- MarsIronPI 5mo ago
  For me it's useful to have a separate directory with my dotfiles repo, since my dotfiles repo's top level directory doesn't correspond to my home directory. I have one subdirectory for each machine.
- uasi 5mo ago
  Git works until you need conditional logic such as platform-specific files or templating.
  - Ferret7446 5mo ago
    There are various options: You can make forks or branches. Perfect for separating your work specific or private configs You can use a filter like https://github.com/darkfeline/qualia-go https://github.com/darkfeline/qualia-go You can use a shell script (stored in the same git repo). You need you run an external tool with dotfile managers anyway, a shell script gives you more flexibility and doesn't need an extra dependency which might break at an inopportune time. The last thing you need is your dotfile manager breaking when you're setting up a new machine (ask me how I know)
    - uasi 5mo ago
      You can, but forks or branches need constant merging or rebasing (and sometimes conflict resolution) for each one. Clean/smudge filters are fiddly to set up correctly and almost certainly require shelling out to another program, which could break. The second-to-last thing you need is your hand-rolled solution breaking on a new environment. If and when you need several advanced features that a stable dotfiles manager already covers, why roll your own?
  - mixmastamyk 5mo ago
darkteflon 5mo ago
Ok, I came into this thread intending to say “I’ve been using stow for years and am perfectly happy with it”, started RTFA and the comments, realised that I was actually not happy with it, started considering chezmoi then remembered that I had had a pretty great experience building a Nix VM recently. Now I want to use Nix* to manage my multi-machine MacOS and Linux setup (with lots of dotfile config overlap, of course). That’s the HN experience for you. Kind souls: what is currently the blessed way to manage MacOS dots with Nix? I recall there is more than one paradigm - what’s the approach that simplest, most robust and can be adopted incrementally? Edit: Just to say that I think Atuin now also plays in this space. Haven’t checked it out, though.
- theshrike79 5mo ago
  The saying used to be "every application extends until it can read email" Now it should be "every app adds features until it manages dotfiles" :D Dunno why I'd use atuin for dotfile management, but some people seem to like it. It's very good at syncing and managing shell history though.
eximius 5mo ago
I made Janus which is kinda like a less bloated Chezmoi https://github.com/logannc/janus https://github.com/logannc/janus
- cwel 5mo ago
  What was your inspiration for writing this? / What bloat did you shed relative to chezmoi?
gchamonlive 5mo ago
> The trouble is that symlinks cut both ways. Every edit on every machine writes straight through the link into that machine’s clone of the repo I have stow too in my micro DE, use it across a few machines and it's holding up really well. I designed my dotfiles so that changes would happens exclusively to files not tracked by stow. I have .zshrc tracked, but environment goes to .zshenv and general local customisation goes to .local/lib/zsh/overrides.zsh (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deployment-packages/local/lib/zsh/overrides.dist.sh?ref_type=heads https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Hyprland config is tracked but device specific configs live in .config/hype/config/device.conf (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deployment-packages/config/hypr/config/device.dist.conf?ref_type=heads https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Deployment instructions/automation is to just copy dist folders in place, which aren't tracked by stow. It depends on everyone's style. For me personally changes I don't remember having made to files I track in the repo are symptoms that I might need to review how I organize my files. Maybe those changes were something that broke and I forgot to commit after fixing. In any case for me this bidirectional nature of symlinks are a feature, not a bug in this management system.
TeriyakiBomb 5mo ago
I found chezmoi kind of annoying and then just moved to symlinks and a fossil repo. Low tech and low drama
technojamin 5mo ago
I've checked out stow, chezmoi, yadm, and others over the years, but I originally started off by rolling my own dotfiles setup with a Git repo about 6 years ago: https://github.com/jaminthorns/environment https://github.com/jaminthorns/environment I don't really recommend it to others, since there's all these great tools that have the features you need (per-machine config, secrets, templating), but I get a deep satisfaction from the fact that I understand every part of this setup from top to bottom. It only has the functionality I need, and I know it doesn't depend on anything that might become unmaintained since it's just POSIX shell scripts. Even still, I might eventually make the jump to something like chezmoi or nix if I'm not able to implement something I need easily, but that hasn't happened yet.
- nickjj 5mo ago
  > don't really recommend it to others, since there's all these great tools that have the features you need I thought about using any one of those tools but happily chose shell scripts and symlinks instead. It hasn't let me down in almost a decade with https://github.com/nickjj/dotfriedrice https://github.com/nickjj/dotfriedrice and would highly recommend this approach. It's basically a 2,500 line shell script to fully automate setting up a system from scratch in a general purpose / opinionated but customizable way that works on Arch Linux, Debian, Ubuntu, macOS and supports WSL 2 in Windows. I have it running on multiple systems, no need to even fork it since it uses patterns suitable for making changes in git ignored files and also has a config file for certain things. When it comes to setting up a complete desktop environment or even just terminal based tools, dotfiles IMO are more than config files. There's install scripts, packages, system level configs, running commands, OS specific differences and more. It's really nice to be able to run 1 command and have a fresh system ready to go in about 10 minutes. Shell script is probably my favorite language at this point.
  - technojamin 5mo ago
    Haha, I'll elaborate on that a bit. I don't recommend rolling your own setup to most people that I encourage to version their dotfiles. The vast majority of the developers I've met don't have any type of dotfiles setup, so I wouldn't want to recommend something I know would take significantly more work or overwhelm them. If they're going from no versioning to something, that's a huge improvement, and it's nice to get a lot of the advanced features for free. But, for the people who value the "toolbench" of their craft, investing in it over time, and having it grow with them long-term, I will absolutely proselytize the reasons I've stayed with my custom-built setup. You're clearly one of those people, thanks for sharing. :)
cocodill 5mo ago
Someone needs to tell this dude about the git branches.
WhyNotHugo 5mo ago
> The trouble is that symlinks cut both ways. Every edit on every machine writes straight through the link into that machine’s clone of the repo. I find this is a key feature. If a file is edited, git shows it as dirty, and I get to decide if I discard of commit the change. No extra steps required. > By the time Homebrew and a couple of tools have run on a new Mac, files like ~/.zprofile and ~/.gitconfig already exist. I don't get why you'd manually provision those files instead of just putting them in dotfiles. --- Personally, I found that most tools in this space tried to do too much or were too complex. I previously wrote a minimal one in Rust, but eventually re-wrote it into less than 200 lines of shell, which works pretty much anywhere, without having to install anything at all, and is part of the dotfiles repository itself: https://git.sr.ht/~whynothugo/dotfiles/tree/ac97cb196f02cafa53680ea1bacb9de02c5ca6eb/item/sync.sh https://git.sr.ht/~whynothugo/dotfiles/tree/ac97cb196f02cafa...
- kelnos 5mo ago
  The issue is that you don't really see the git dirty/clean status, because you are rarely/never inside the actual git working tree on your machine. I manage my dotfiles with a simple script that symlinks, and when I go and edit one of those files (through the symlink), I'm either editing from my homedir, or from the directory containing the symlink. When the edit is done, I don't see any git status, because I'm not inside the git repo working tree. I end up with the same issue as OP: months and months later I'll pop into ~/.dotfiles (where I keep the git repo), and see the tree is dirty, with all these random changes I've made that I don't really remember all that well. The difference for me vs. the OP is that I consider it a minor inconvenience, spend a few minutes cleaning up and committing, and go about my day. It also helps that I'm pretty much a single-machine guy. I have the dotfiles on random server-like machines in my house, but I basically never edit them on those machines; all edits happen on my laptop, so I never have a problem with conflicts. I could definitely see how this could get annoying for people who edit their dotfiles on several different machines.
  - duskdozer 5mo ago
    For this, I just added a section to my prompt (bash) showing the state of my dotfiles repo (using yadm). This made sense to me because I'd already done this for a git repo in my current dir. I originally rolled my own but eventually found https://github.com/romkatv/gitstatus https://github.com/romkatv/gitstatus which is much faster. So, along with background fetches/pushes, at any point I can tell what revision my dotfiles repo is on and whether it's clean, up to date, conflicted, etc. The time cost for my whole prompt is <20ms.
wyclif 5mo ago
I wrote a short post about this a while back: https://stoddart.github.io/development/tools/open-source/reviews/2024/09/08/managing-dotfiles-with-chezmoi.html https://stoddart.github.io/development/tools/open-source/rev... This one is good, though, and very thorough—even though it's Mac-centric.
senotrusov 5mo ago
I evaluated most of the popular dotfile management tools and found them far too complex for the problems they try to solve. I then used stow for about a year just to see whether symlinks would cause any issues. They did. Eventually, I wrote my own bidirectional sync tool that synchronizes a git checkout (for example, ~/.dotfiles) with the actual home directory. I run it as a systemd service, so I can simply edit or delete files in ~/.dotfiles, and everything else happens automatically. I can add or remove files in the repository, and they will automatically be created or removed in their synchronized locations. At the same time, the target directories can contain other unrelated files, including an entire $HOME, and this does not interfere with synchronization in any way. The bidirectional sync is particularly useful when a program, such as vs code, decides to modify its own configuration files, or when I'm feeling lazy and just want to edit ~/.bashrc directly and commit the changes later. Achieving this requires some careful logic that, hopefully, I've managed to get right. At least at the time I wrote it, I hadn't seen these implemented in other systems. Oh, and I use the same sync for some files I need to /etc, only for that I run sudo scripts and dont' have a always-on service for obvious reasons. I'd be happy if someone else found it useful too: https://github.com/senotrusov/etcdotica https://github.com/senotrusov/etcdotica
taegee 5mo ago
I just ditched Chezmoi in favor of GNU Stow …
mmmmbbbhb 5mo ago
Honestly, I think you'd benefit from vibe coding your own solution. That way it fits you like a glove.
globular-toast 5mo ago
The only thing currently annoying me with my Stow setup is handling machine-specific changes. I have a "work" branch in my repo that I have to keep rebased on my master branch. Weird things happen if that rebase causes conflicts in the git config! It's also just annoying. Does Chezmoi have a better solution for that? Or is there a better way using Stow?
- theshrike79 5mo ago
  With chezmoi you'd create templates from the config files, which would apply/ignore specific bits depending on whatever selector you want (machine name, OS etc)
ceving 5mo ago
I don't understand why anyone would bother doing something like Stow. I keep my home directory directly in a Git repository that ignores all files by default, and for systems with specific configurations, I simply create a branch.
- theshrike79 5mo ago
  But if you have 6-10 machines you use and they're all a bit different, doesn't the branching get a bit tedious when you want to edit something that's common for all? Vs. the chezmoi way of keeping everything common except using templates for diverging files.
swaranga 5mo ago
I wrote dloom for myself after finding Stow not flexible enough https://github.com/dloomorg/dloom https://github.com/dloomorg/dloom Short blogpost for the TLDR: https://swaranga.dev/posts/dloom-the-dotfile-manager-i-wanted/ https://swaranga.dev/posts/dloom-the-dotfile-manager-i-wante...

141 points by speckx 5mo ago

I must've tried to set up stow five or six times over the years, in between various hand rolled custom setups. I can't put my finger on why but I set up chez moi & it's been my setup since, much longer than any previous solution. Chez moi is definitely not without its rough edges but it seems to have gotten the subtle essentials right enough for adhd me to not have abandoned it yet.

guhcampos 5mo ago
I used stow for a long time, then tried Ansible, but eventually settled into good old Make. `make dotfiles` just creates a bunch of symlinks, takes 5 minutes, all good and happy. Everything is modular, declarative, simple. Never looked back.
- lucideer 5mo ago
  I think this is likely a part of the friction for a lot of people - symlinks. There's roughly two main ways to manage dotfiles: - symlink - copy & sync The 2nd (what chez moi does) is pretty hard to get right from a UX perspective.
sureglymop 5mo ago
Same here. I would say chezmoi has almost a bit too many features. If one is into yak shaving there is a lot to explore. It's only a negative for me because I forget half of them everytime I read the docs. But I can hardly blame it for that, it's great!
linhns 5mo ago
I nearly jumped from GNU Stow, but settled when I find the —-no-folding flag

drdexebtjl 5mo ago

I had similar problems with GNU Stow, but switched to Nix and Home Manager instead. I think Chezmoi's templates and file naming conventions don't click for me, but it's nice to see a good variety in this problem space.

colordrops 5mo ago
People shy from Nix because of supposed complexity but it really is the only real solution to this sort of problem. It's not really that much more difficult to learn, and in fact if you are willing, AI works really well generating nix config.
- chungy 5mo ago
  Guix solves the same problem in similar ways, though it uses Scheme as its configuration language.
  - drdexebtjl 5mo ago
    Sadly it doesn't work on macOS, unlike Nix.
    - pkulak 5mo ago
      Or hardware.
      - sham1 5mo ago
        It absolutely works with hardware. And it's not that difficult to add channels for extra software like a tainted Linux kernel. And in return one gets a saner programming language than the Nix language.
- drdexebtjl 5mo ago
  It took me a single afternoon to learn the basics and start using it. Contrary to what I initially thought, I didn't have to migrate all of my dotfiles at once. Then over the next couple of days, Codex migrated everything else for me. One major benefit for me is that I no longer need to have once-in-a-while tools installed, because I can always spin up a temporary shell with `nix-shell -p packageName`. This significantly decreased the amount of software I have in my environment. This works great with agentic coding. Agent wants to run `ripgrep`, but you don't have it? Tell it to run `nix run nixpkgs#ripgrep` instead. But the biggest benefit is that now that you know Nix! So you can start using it to create reproducible development environments and uninstall mise, asdf, nvm, pyenv, etc. You can spin up reproducible servers running NixOS and never touch Ansible again. You can even install it in your router. Or you can do none of that and continue just using it for your dotfiles. It plays nice with other tools.

rochak 5mo ago

I've been using [yadm](https://yadm.io/ https://yadm.io/) instead which works really well!

laurentlbm 5mo ago
I've been happy with yadm for few years now. I had tried chezmoi, but preferred yadm. I don't remember my exact reasons though...
- markstos 5mo ago
  I looked at Stow and Chezmoi and also have stuck with YADM. The exact reason is that YADM is so simple and intuitive because it's basically Git-for-dotfiles with so little to learn. Yet it also manages to support alternate and template files.
- duskdozer 5mo ago
  I looked around at a bunch but settled on yadm for basically just using a normal git workflow. I wanted to just edit the files directly, know what it's doing, and not change how I worked. I really dislike the `<tool> edit/run/<standard command>` UI pattern that's fairly common now.
jdxcode 5mo ago
I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm https://github.com/thoughtbot/rcm

spudlyo 5mo ago

It's great to manage your dotfiles, but I took it a step farther. I rebuilt the minimal Linux desktop environment of my dreams (startx, xinit, i3, i3status etc) with Ansible. It begins from a vanilla Ubuntu server 24.04.4 install. I bootstrapped it using a KVM + spice setup (using a spare physical SSD rather than a virtual one) and iterating over and over again until I finally got everything mostly working. I then booted off that physical disk, and kept iterating until everything was perfect. I've since adapted the setup to work on virtual aarch64 on macOS. I just recently tuned it to work on a crappy old Haswell Dell laptop, now properly detecting and configuring hardware vaapi capabilities, backlight, battery, trackpad, trackpoint, etc. Pretty snazzy, watching YouTube in Firefox on a 13 year old laptop with hardware h264 decode and everything tuned exactly to my liking.

anuramat 5mo ago
don't want to be that guy, but have you tried nix?
- spudlyo 5mo ago
  I tried GUIX a few times, but ultimately I couldn't quite get it working exactly the way I wanted it to work. I also didn't like the ugly filesystem layout that the store requires. I may get over it and revisit at some point. It will be a lot of work, but on the plus side I'll have a reason to learn scheme.
trallnag 5mo ago
I did that too across three devices and it turned out to be a huge time sink similar to tinkering with a personal server

mmh0000 5mo ago

I’ve always managed this problem in a different way. I don’t know if my way is better, but it works really well for me. I treat my powerful desktop computer as my main machine. Then I have a bunch of laptops. Then I just rsync my entire home directory out to all the laptops. From there. The rule is quite simple. Any file created on a laptop are considered ephemeral. If I create data that I have to keep. It gets rsynced back the other direction to the main machine. This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process

shevy-java 5mo ago
Interesting. I go about this differently. I have one master setting and from there ruby just autogenerates anything I'd ever need on other computers. If ruby is unavailable then I just copy the generated files. But I only edit the master setting to enable what I need. > This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process I feel in a similar way but not with shell scripts. Ruby autogenerates them if I need them too. Ruby is my ultimate glue to hold together everything.
deleted 5mo ago
[deleted]
cwel 5mo ago
> rsync my entire home directory out to all the laptops Interesting approach. Whether it could be considered 'better' or not depends on what your 'handful of shell scripts' do.
mixmastamyk 5mo ago
I feel like git or other vcs would be a bit safer. I could see myself syncing the wrong way.

arrakeen 5mo ago

i feel like using GNU stow to manage your dotfiles has always been a hack.. has it ever been a supported usecase? stow is an indispensable tool for me to manage /usr/local for manually installed software. my workflow goes: ./configure --prefix=/usr/local/stow/myapp make && make install stow myapp now, myapp and all its supporting files are in the right place in /usr/local. if i want to "uninstall", i just run stow -D myapp

WCSTombs 5mo ago
I like to use environment modules [1] (or lmod [2]) for that purpose. You can make each manually built software package available or not on a per-shell-session basis, just by running module load myapp or module unload myapp in the shell where you want it (or don't). The small downside is that it only works with software that actually uses the standard environment variables like PATH, CPATH, etc. for their intended purposes rather than hardcoding filesystem paths, but in my experience it's rare to find something that doesn't. Also, you have to write a modulefile for each package, but that's not a big deal. [1]: https://modules.readthedocs.io/en/latest/ https://modules.readthedocs.io/en/latest/ [2]: https://lmod.readthedocs.io/en/latest/ https://lmod.readthedocs.io/en/latest/

shevy-java 5mo ago

I hate . dirs. In fact, I hate them so much that I don't use them. My configuration lives primarily in .yml files. These are kept super-simple. When need be and another format is required, ruby autogenerates these for me. For instance, all my bash aliases are kept in .yml files which then get turned into bash rc files or any other target format for other shells. Same for most of my other configuration too - not always .yml but usually some text file. I never understood the neet for .foobar directories or files. They just hide a system that is intrinsically ugly and needlessly complicated.

RunningDroid 5mo ago
You might like xdg-ninja‡ then, it tells you what program put which item in your $HOME and how to move it to ~/.config or $XDG_CONFIG_HOME. ‡: https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja
chuckadams 5mo ago
Found the Kubernetes guy ;)

QwenGlazer9000 5mo ago

Chezmoi strikes a nice balance between the overkill of home-manager while still being more powerful than simpler solutions. Yadm is another alternative, the main thing I don't like about it though is that I'm not a fan of cross OS dotfiles. Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit. As powerful as the templating in chezmoi is, I think it should be considered a last resort and only used for simple files. They break your editor features like highlighting.

cwel 5mo ago
> Having niri files on my work Mac and aerospace dotfiles on Linux annoys me quite a bit https://www.chezmoi.io/reference/special-files/chezmoiignore/ https://www.chezmoi.io/reference/special-files/chezmoiignore... > They break your editor features like highlighting https://github.com/alker0/chezmoi.vim https://github.com/alker0/chezmoi.vim

pkulak 5mo ago

Once you hit the Chezmoi stage, you're only about 6 months from Nix and Home Manager. I mean, why climb _almost_ to the top of a mountain and then just sit down?

halostatue 5mo ago
I've bounced off Nix every time I tried it, before I even started trying something like Home Manager. I've been using (and contributing to) chezmoi for ~6 years now. Given that it has first-class integration with secrets managers, I suspect that it does things that Home Manager can't.
- linsomniac 5mo ago
  >I've bounced off Nix every time I tried it, before I even started trying something like Home Manager. I did too. Until I tried configuring it with Claude Code. I'll give you my money back guarantee on it.
  - bronson 5mo ago
    Vibed infrastructure? That sounds like it undoes a lot of Nix's advantages.
- redog 5mo ago
  > it has first-class integration with secrets managers Meow?
  - halostatue 5mo ago
    No slight involved. The chezmoi integration with 1Password is excellent; for those who prefer Bitwarden, it supports both the default CLI (which has some inexcusable behaviours for a security product, IMO) and `rbw` (which is infinitely better than the default CLI). It supports `pass`, `gopass`, `passage`, AWS Secrets Manager, KeePass, and several other approaches. It was the work of a couple of minutes to enable a secret for a Claude Code API token to be mounted in a VM where I'm running Claude for a project where the value is pulled from 1Password and I can regenerate it and reapply without fear. If one doesn't have to worry about secrets in one's dotfiles, I'm sure that other dotfile managers including Nix with Home Manager will suffice. I do, so they won't.

vsviridov 5mo ago

Switched to Chezmoi from random assortment of manually authored scripts. The workflow takes some getting used to, because I constantly edit the actual files without calling `chezmoi edit` first, and have to merge. I like that when combined with `mise` (https://mise.jdx.dev https://mise.jdx.dev) I can roll out a new computer in 2-3 commands and have my entire environment configured the way I like, with neovim and all the plugins and language servers.

deleted 5mo ago
[deleted]
LVB 5mo ago
I never did get used to the Chezmoi workflow. `chezmoi edit` never became muscle memory, and I was constant finding myself resolving diffs and what not.
- vsviridov 5mo ago
  BeyondCompare 2-way merge usually resolves everything automatically, and it's set up as the default mergetool for me, so it's only a couple of clicks... But yeah, takes some muscle memory.

groos 5mo ago

~50 years of distributed systems research and this is a problem we still have to deal with today. Sad!

jdxcode 5mo ago

It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html https://mise.jdx.dev/bootstrap.html It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd. EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend checking it out.

halostatue 5mo ago
Are there plans to support MacPorts as a packaging system? I only use Homebrew for casks, because I find it unreliable for core development tools.
- jdxcode 5mo ago
  Haven't looked into it but agents are so good at this I bet it'll be trivial to add
0cf8612b2e1e 5mo ago
I am quite intrigued. With the sorry state of security, I am doing everything in VMs and have been trying to settle on the best way to setup a new machine. The process is so clunky that I end up defaulting to bigger instances than I should (more pets than cattle). Being able to centralize this config is far more attractive than having a separate Ansible or pyinfra process. Edit: The docs on this are very encouraging! However, it is not clear- what is experimental? Anything notably buggy or churning? Any far off features you hope to implement some day?
- throawayonthe 5mo ago
  i would reach for atomic fedora personally, maybe with bluebuild
  - 0cf8612b2e1e 5mo ago
    That still feels like more external tooling, plus letting the distro make my packaging decisions. I am already using mise, so this is an almost free boon without more complexity.

cue_the_strings 5mo ago

[dead]

sgarland 5mo ago

I learned about Stow after I found out about Chezmoi, and felt like Chezmoi was the better fit for me. I make heavy use of templating to keep work / personal aliases and functions separate, and could not be happier with the outcome.

wyclif 5mo ago
It is definitely a better fit because Stow was never intended to function as a manager for dotfiles under version control.

blop 5mo ago

I use syncthing to automatically sync my dotfiles git directory across PC/laptops, and stow to manually update symlinks when I add a new dotfile (the content of existing dotfiles is synced by syncthing already) That way I don't have to remember to commit+push+pull changes to existing dotfiles (like bashrc or vimrc which I edit often) to sync them to other machines, it happens automatically in almost real time as soon as the file is saved on one of my machines (syncthing uses inotify to detect changes on monitored directories)

c-hendricks 5mo ago
This is what I did too. My dotfiles used a custom install process that didn't really handle ~/.config very well, so I switched to stow, and then added syncthing because the push + pull dance got too annoying. Really happy with it.

Ferret7446 5mo ago

I've never really understood why people get so fancy with their setups when you can just plop a git repo into your home directory. I suspect it has to do with people being unfamiliar with git.

MarsIronPI 5mo ago
For me it's useful to have a separate directory with my dotfiles repo, since my dotfiles repo's top level directory doesn't correspond to my home directory. I have one subdirectory for each machine.
uasi 5mo ago
Git works until you need conditional logic such as platform-specific files or templating.
- Ferret7446 5mo ago
  There are various options: You can make forks or branches. Perfect for separating your work specific or private configs You can use a filter like https://github.com/darkfeline/qualia-go https://github.com/darkfeline/qualia-go You can use a shell script (stored in the same git repo). You need you run an external tool with dotfile managers anyway, a shell script gives you more flexibility and doesn't need an extra dependency which might break at an inopportune time. The last thing you need is your dotfile manager breaking when you're setting up a new machine (ask me how I know)
  - uasi 5mo ago
    You can, but forks or branches need constant merging or rebasing (and sometimes conflict resolution) for each one. Clean/smudge filters are fiddly to set up correctly and almost certainly require shelling out to another program, which could break. The second-to-last thing you need is your hand-rolled solution breaking on a new environment. If and when you need several advanced features that a stable dotfiles manager already covers, why roll your own?
- mixmastamyk 5mo ago

darkteflon 5mo ago

Ok, I came into this thread intending to say “I’ve been using stow for years and am perfectly happy with it”, started RTFA and the comments, realised that I was actually not happy with it, started considering chezmoi then remembered that I had had a pretty great experience building a Nix VM recently. Now I want to use Nix* to manage my multi-machine MacOS and Linux setup (with lots of dotfile config overlap, of course). That’s the HN experience for you. Kind souls: what is currently the blessed way to manage MacOS dots with Nix? I recall there is more than one paradigm - what’s the approach that simplest, most robust and can be adopted incrementally? Edit: Just to say that I think Atuin now also plays in this space. Haven’t checked it out, though.

theshrike79 5mo ago
The saying used to be "every application extends until it can read email" Now it should be "every app adds features until it manages dotfiles" :D Dunno why I'd use atuin for dotfile management, but some people seem to like it. It's very good at syncing and managing shell history though.

eximius 5mo ago

I made Janus which is kinda like a less bloated Chezmoi https://github.com/logannc/janus https://github.com/logannc/janus

cwel 5mo ago
What was your inspiration for writing this? / What bloat did you shed relative to chezmoi?

gchamonlive 5mo ago

> The trouble is that symlinks cut both ways. Every edit on every machine writes straight through the link into that machine’s clone of the repo I have stow too in my micro DE, use it across a few machines and it's holding up really well. I designed my dotfiles so that changes would happens exclusively to files not tracked by stow. I have .zshrc tracked, but environment goes to .zshenv and general local customisation goes to .local/lib/zsh/overrides.zsh (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deployment-packages/local/lib/zsh/overrides.dist.sh?ref_type=heads https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Hyprland config is tracked but device specific configs live in .config/hype/config/device.conf (https://gitlab.com/gabriel.chamon/archie/-/blob/main/deployment-packages/config/hypr/config/device.dist.conf?ref_type=heads https://gitlab.com/gabriel.chamon/archie/-/blob/main/deploym...). Deployment instructions/automation is to just copy dist folders in place, which aren't tracked by stow. It depends on everyone's style. For me personally changes I don't remember having made to files I track in the repo are symptoms that I might need to review how I organize my files. Maybe those changes were something that broke and I forgot to commit after fixing. In any case for me this bidirectional nature of symlinks are a feature, not a bug in this management system.

TeriyakiBomb 5mo ago

I found chezmoi kind of annoying and then just moved to symlinks and a fossil repo. Low tech and low drama

technojamin 5mo ago

I've checked out stow, chezmoi, yadm, and others over the years, but I originally started off by rolling my own dotfiles setup with a Git repo about 6 years ago: https://github.com/jaminthorns/environment https://github.com/jaminthorns/environment I don't really recommend it to others, since there's all these great tools that have the features you need (per-machine config, secrets, templating), but I get a deep satisfaction from the fact that I understand every part of this setup from top to bottom. It only has the functionality I need, and I know it doesn't depend on anything that might become unmaintained since it's just POSIX shell scripts. Even still, I might eventually make the jump to something like chezmoi or nix if I'm not able to implement something I need easily, but that hasn't happened yet.

nickjj 5mo ago
> don't really recommend it to others, since there's all these great tools that have the features you need I thought about using any one of those tools but happily chose shell scripts and symlinks instead. It hasn't let me down in almost a decade with https://github.com/nickjj/dotfriedrice https://github.com/nickjj/dotfriedrice and would highly recommend this approach. It's basically a 2,500 line shell script to fully automate setting up a system from scratch in a general purpose / opinionated but customizable way that works on Arch Linux, Debian, Ubuntu, macOS and supports WSL 2 in Windows. I have it running on multiple systems, no need to even fork it since it uses patterns suitable for making changes in git ignored files and also has a config file for certain things. When it comes to setting up a complete desktop environment or even just terminal based tools, dotfiles IMO are more than config files. There's install scripts, packages, system level configs, running commands, OS specific differences and more. It's really nice to be able to run 1 command and have a fresh system ready to go in about 10 minutes. Shell script is probably my favorite language at this point.
- technojamin 5mo ago
  Haha, I'll elaborate on that a bit. I don't recommend rolling your own setup to most people that I encourage to version their dotfiles. The vast majority of the developers I've met don't have any type of dotfiles setup, so I wouldn't want to recommend something I know would take significantly more work or overwhelm them. If they're going from no versioning to something, that's a huge improvement, and it's nice to get a lot of the advanced features for free. But, for the people who value the "toolbench" of their craft, investing in it over time, and having it grow with them long-term, I will absolutely proselytize the reasons I've stayed with my custom-built setup. You're clearly one of those people, thanks for sharing. :)

cocodill 5mo ago

Someone needs to tell this dude about the git branches.

WhyNotHugo 5mo ago

> The trouble is that symlinks cut both ways. Every edit on every machine writes straight through the link into that machine’s clone of the repo. I find this is a key feature. If a file is edited, git shows it as dirty, and I get to decide if I discard of commit the change. No extra steps required. > By the time Homebrew and a couple of tools have run on a new Mac, files like ~/.zprofile and ~/.gitconfig already exist. I don't get why you'd manually provision those files instead of just putting them in dotfiles. --- Personally, I found that most tools in this space tried to do too much or were too complex. I previously wrote a minimal one in Rust, but eventually re-wrote it into less than 200 lines of shell, which works pretty much anywhere, without having to install anything at all, and is part of the dotfiles repository itself: https://git.sr.ht/~whynothugo/dotfiles/tree/ac97cb196f02cafa53680ea1bacb9de02c5ca6eb/item/sync.sh https://git.sr.ht/~whynothugo/dotfiles/tree/ac97cb196f02cafa...

kelnos 5mo ago
The issue is that you don't really see the git dirty/clean status, because you are rarely/never inside the actual git working tree on your machine. I manage my dotfiles with a simple script that symlinks, and when I go and edit one of those files (through the symlink), I'm either editing from my homedir, or from the directory containing the symlink. When the edit is done, I don't see any git status, because I'm not inside the git repo working tree. I end up with the same issue as OP: months and months later I'll pop into ~/.dotfiles (where I keep the git repo), and see the tree is dirty, with all these random changes I've made that I don't really remember all that well. The difference for me vs. the OP is that I consider it a minor inconvenience, spend a few minutes cleaning up and committing, and go about my day. It also helps that I'm pretty much a single-machine guy. I have the dotfiles on random server-like machines in my house, but I basically never edit them on those machines; all edits happen on my laptop, so I never have a problem with conflicts. I could definitely see how this could get annoying for people who edit their dotfiles on several different machines.
- duskdozer 5mo ago
  For this, I just added a section to my prompt (bash) showing the state of my dotfiles repo (using yadm). This made sense to me because I'd already done this for a git repo in my current dir. I originally rolled my own but eventually found https://github.com/romkatv/gitstatus https://github.com/romkatv/gitstatus which is much faster. So, along with background fetches/pushes, at any point I can tell what revision my dotfiles repo is on and whether it's clean, up to date, conflicted, etc. The time cost for my whole prompt is <20ms.

wyclif 5mo ago

I wrote a short post about this a while back: https://stoddart.github.io/development/tools/open-source/reviews/2024/09/08/managing-dotfiles-with-chezmoi.html https://stoddart.github.io/development/tools/open-source/rev... This one is good, though, and very thorough—even though it's Mac-centric.

senotrusov 5mo ago

I evaluated most of the popular dotfile management tools and found them far too complex for the problems they try to solve. I then used stow for about a year just to see whether symlinks would cause any issues. They did. Eventually, I wrote my own bidirectional sync tool that synchronizes a git checkout (for example, ~/.dotfiles) with the actual home directory. I run it as a systemd service, so I can simply edit or delete files in ~/.dotfiles, and everything else happens automatically. I can add or remove files in the repository, and they will automatically be created or removed in their synchronized locations. At the same time, the target directories can contain other unrelated files, including an entire $HOME, and this does not interfere with synchronization in any way. The bidirectional sync is particularly useful when a program, such as vs code, decides to modify its own configuration files, or when I'm feeling lazy and just want to edit ~/.bashrc directly and commit the changes later. Achieving this requires some careful logic that, hopefully, I've managed to get right. At least at the time I wrote it, I hadn't seen these implemented in other systems. Oh, and I use the same sync for some files I need to /etc, only for that I run sudo scripts and dont' have a always-on service for obvious reasons. I'd be happy if someone else found it useful too: https://github.com/senotrusov/etcdotica https://github.com/senotrusov/etcdotica

taegee 5mo ago

I just ditched Chezmoi in favor of GNU Stow …

mmmmbbbhb 5mo ago

Honestly, I think you'd benefit from vibe coding your own solution. That way it fits you like a glove.

globular-toast 5mo ago

The only thing currently annoying me with my Stow setup is handling machine-specific changes. I have a "work" branch in my repo that I have to keep rebased on my master branch. Weird things happen if that rebase causes conflicts in the git config! It's also just annoying. Does Chezmoi have a better solution for that? Or is there a better way using Stow?

theshrike79 5mo ago
With chezmoi you'd create templates from the config files, which would apply/ignore specific bits depending on whatever selector you want (machine name, OS etc)

ceving 5mo ago

I don't understand why anyone would bother doing something like Stow. I keep my home directory directly in a Git repository that ignores all files by default, and for systems with specific configurations, I simply create a branch.

theshrike79 5mo ago
But if you have 6-10 machines you use and they're all a bit different, doesn't the branching get a bit tedious when you want to edit something that's common for all? Vs. the chezmoi way of keeping everything common except using templates for diverging files.

swaranga 5mo ago

I wrote dloom for myself after finding Stow not flexible enough https://github.com/dloomorg/dloom https://github.com/dloomorg/dloom Short blogpost for the TLDR: https://swaranga.dev/posts/dloom-the-dotfile-manager-i-wanted/ https://swaranga.dev/posts/dloom-the-dotfile-manager-i-wante...