Yeah, I started with the direct symlink long ago too ("declarative" lines that were just shell commands sourced at the top). I now have a more…complex setup tha

Yeah, I started with the direct symlink long ago too ("declarative" lines that were just shell commands sourced at the top). I now have a more…complex setup that uses CMake. The basic setup is: group/ (e.g., "devel" or "pim") program/ (e.g., "vim" or "mutt") CMakeLists.txt (lists files and packages needed; I use Fedora) config/ local/ repeat for each program, sorted into groups. Each program is added via a function that wraps `add_subdirectory` in an option asking if I want to enable that project. It also takes a list of dependencies (so, e.g., `mutt` is hidden if I turn off `msmtp` or `nvim` since it needs it in its configuration). Each program's CMake code declares what needs symlinked, directories to be made, permission bits, etc. This is used to also write out a "validation" script to ensure symlinks are accurate and to notice untracked config files and such. I then just configure, turn the programs I plan on using on in the project and then "build" it. It also generates a `dnf install` argument list for me to install anything needed for these configurations. The symlink setup is actually `$HOME/.path` (to avoid the repo from having hidden files; skippable if needed in the CMake code) -> `$builddir/group/program/path` -> `$srcdir/group/program/path`. This way, turning off a program nukes the build tree and then I can just go and look for broken symlinks in `$HOME` to clean up. Per-host bits overlay cleanly since I use split configs where possible (i.e., `include *.rc`). One nice thing about using CMake is that I can also have `add_custom_command` at hand to generate files if needed (I use it to generate `xcompose` combinations).