4 ms·

dot files, configs and hosts are now managed in ansible. First solution a decade ago was to have a git repo and dotfiles were linked directly into the working

by yonrg 4y ago

dot files, configs and hosts are now managed in ansible. First solution a decade ago was to have a git repo and dotfiles were linked directly into the working dir. This was nuts. The dots were changed immediately, when checking out other branches. And slight differences between hosts were not easily manageable. A branch per host was not a solution. I learned from those mistakes and wrote an installer script for that repo which copied/rsynced files from repo into ~ Still, slight changes between hosts were not easily manageable and I was thinking about a templating mechanism... but then ansible became a thing which I happily adopted. Might be too much for most users, but it helps me managing many machines.

mathstuf 4y ago
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).

by yonrg 4y ago

mathstuf 4y ago

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).