dotfile management

Updated 2021-03-09

Like most people who work in a unix-y environment, I have a well-maintained menagerie of dotfiles. And like many, I keep them in version control for easy sharing between machines, tracking of changes, and all the usual reasons to use version control. I have my own spin on it, however.

This script was motivated by the following:

  1. I didn’t want a .git or .hg in my home directory itself.
  2. I was using Mercurial, which makes it a little hard to see the effects of incoming changes without actually applying them in the working copy.
  3. I had accounts on multiple systems with different operating systems and distributions, which requires some differences among copies of the “same” file, and not all programs support conditionals and other logic in their configuration syntax.
  4. I wanted some limited macro substitution (e.g. for the location of my music collection, referred to by a few different scripts).

Together, these suggested a solution: keeping dotfiles in a separate hierarchy, copying them to their real locations only when instructed by the user, and applying a simple pre-processor as part of the copy step.

You can see the result on github.

I won’t repeat the README or include the source here (it comes to 468 lines of Python), but some commentary:

I’ve been very happy with dotstuff for my own use over the years (it was written in 2008). I’m up to 701 revisions on my personal repo.

I used to keep in my repo a bunch of small text files that weren’t dotfiles, but things that I wanted to have synchronized and backed up. These days I’ve moved most of that data to cloud services.

As much of the Linux-using world has standardized on Ubuntu, I find I have to use the environment feature and conditionals less. I used to use conditionals to keep work-related shell aliases and things off of my personal machines, but now that I work on a personal laptop, that’s no longer useful. So it’s quite possible I could get by without those features now. (For reference, in my repo, there are 103 instances of dotstuff directives in about 11K lines of text.)

Similarly, the feature that lets me pull in changes from the remote and get a diff of what will actually change in my dotfiles before I activate those changes, wouldn’t be as useful if I were using git, because it has more features to handle that workflow natively.

I’m therefore forced to conclude that dotstuff is somewhat archaic, and if I was creating it today it would be much smaller and simpler. I’ll still keep using it out of momentum, though.

I’m still using dotstuff for all my personal configuration needs (now up to 1084 revisions). I updated it to Python 3 and converted the repo to git. I use the conditional feature less and less, but it’s nice to have in a few key places.

I’ve moved to NixOS on my personal Linux machines and keep my NixOS configuration in my dotstuff repo, along with a few scripts to manage it. In the Nix world, of course, the popular solution in this niche is home-manager. Translating all of my configuration to home-manager would take a decent amount of effort, so I’m not rushing to do it soon, but I probably will eventually.