-
Notifications
You must be signed in to change notification settings - Fork 48
In my opinion, Dotter has several advantages over GNU Stow.
Dotter can do literally everything Stow can.
In fact, you can use it the same way by having a package for each folder in your repository that is pointed to ~ as its target.
For example, Brandon could use this as his global.toml:
[bash.files]
bash = "~"
[uzbl.files]
uzbl = "~"
[vim.files]
vim = "~"local.toml, and Dotter would instantly work with his already existing dotfile repository.
This could be a good starting point for your migration!
GNU Stow is a symlink farm manager.
As such, it does not support templating, and especially doesn’t support the per-machine templating that you can do using local.toml variable overrides.
Read more about templating here.
Not only does Dotter allow you to change the contents of your deployed files between machines, it also allows you to change their location.
For example, on Windows NeoVim reads its configuration from C:/Users/USERNAME/AppData/Local/nvim/init.vim, while on Linux it reads from ~/.config/nvim/init.vim.
If you wanted to use the same dotfile repository for your Linux and Windows machines, you would not be able to do it using Stow.
However with Dotter, you can override vimrc’s target location in your local.toml and then deploy the files without any problem.
Read more about configuration here.
Files that use the templating feature are not symlinked to their destination - they cannot be, since their pre-templated contents differ from the target file’s contents. Therefore, they must be copied there.
That means that if you want to edit your source file, you need to run Dotter again in order for it to update the target file.
When you choose to make a certain file a template, you are making a trade-off - you get the benefits of a templated file, but you lose the benefits of a symlinked file.
Template’s benefits:
-
Ability to use all of the templating features - substitution, logic, helpers, complex target actions
-
If applications modify the target file, you are notified next time Dotter runs - with symlinks, it’s silently updated in the repository
Symlink’s benefits:
-
Automatic updating - for example, it’s possible to use a GUI application to modify the configuration and have it update in the repository.
Running dotter watch will make it run continuously and wait for changes in the repository, deploying when they happen.
This is helpful to mitigate the disadvantage of templates - it will update them instantly when you modify them, making them "feel" like symlinks while it runs (at least in the source → target direction).
Dotter supports hooks - files which are executed when a certain action happens. Currently supported:
-
Before a deploy, at
.dotter/pre_deploy.sh -
After a deploy, at
.dotter/post_deploy.sh -
Before an undeploy, at
.dotter/pre_undeploy.sh -
After an undeploy, at
.dotter/post_undeploy.sh
Note that these files are rendered as a template, which means they can use all of the logic and variables that a regular templated file can.
Use this for example with the dotter.packages variable to turn on/off sections of such a script.
On linux, the template is cached in .dotter/cache/.dotter/pre_deploy.sh, and the rendered contents are piped into sh.
On windows, the file is rendered to .dotter/cache/.dotter/pre_deploy.bat and then executed directly.