GNU Stow alternative: Dotfiles Pro
GNU Stow is a symlink farm manager: you keep your dotfiles in a repository organized into "packages," and Stow symlinks them into $HOME. It's elegant and dependency-light, but it does exactly one thing, link files. Dotfiles Pro does that job too (link, copy, or template per file) and manages the whole machine: packages, system configuration, repositories, and key-level settings.
GNU Stow vs Dotfiles Pro
- Mechanism: Stow is a symlink farm; the
dotfilesrole links too by default, but each file can also be copied or templated, and roles manage the configs they know at the key level instead of as whole files. - Templating: Stow has none (a file is the same on every machine); Dotfiles Pro renders per-machine config from your vars with Jinja.
- Machine state: Stow manages no packages, services, or repositories; Dotfiles Pro does, in the same run.
- Drift: re-running Stow re-links; Dotfiles Pro applies the whole machine back to its declared state.
When GNU Stow is the better choice
- You want the simplest possible, near-zero-dependency approach.
- Your dotfiles are identical across machines (no templating needed).
- You don't need packages or system state managed.
When to choose Dotfiles Pro
- You're tired of a symlink farm plus a
setup.shfor "everything else." - Packages, services, and repositories should be managed alongside the files.
- Your several machines run from one config repo, and a team can share a baseline collection on top.
Migrating from GNU Stow
Point the dotfiles role at your repo and list each package's files in dotfiles_list, it links them the way stow did, folded into the apply, with backup and pruning. Then promote the configs a role manages (git identity, shell aliases) to settings. The migration guide walks it package by package.
See the full alternatives comparison for the scored tables.