Strong opinions, weakly held

Describing my ideal dotfile installer

One of my goals is to perfect my dotfile setup. I suppose this means that I’m not quite all in as a manager yet. Every self-respecting developer has their dotfiles in a public repository on GitHub, but I have a couple of requirements beyond just being able to clone my dotfiles on any machine. They are:

  • I have some dotfile information that can go into a public repository, and some configuration and preferences that must live behind the firewall for use on work computers. I’d like for the behind the firewall stuff to be a supplement to my public dotfile information. For example, my .vimrc should be the same everywhere. My .bashrc should be mostly the same, with a few additions of stuff for work. I may also have some dotfiles that are exclusive to my work environment. Any setup should understand how to clone files first from my public repo, and then apply the dotfiles from the private repository.
  • Homebrew can be bootstrapped using a single shell command. (Check it out under the Install Homebrew heading on the Homebrew page.) I’d like to have something similar for my dotfiles. Not only would it be cool, but it would also be useful at work. All of our servers at work are managed using Chef. It’s possible to check your dotfiles into our Chef repository and have them deployed automatically on all of our servers, so that when you log into a new server, it already has your preferred environment set up. I have two issues with just putting my dotfiles into Chef. The first is that I don’t want to clutter up the Chef repo with my junk. If everyone does that, our Chef runs will slow down. The second is that I don’t want to have to update them in two places whenever I make changes. If I have a bootstap command that pulls all of my dotfiles from their regular location, I can just put that into Chef.

I’m going to start hacking away on creating a dotfile installer that meets both of these requirements and blogging about my progress. My public dotfiles are in a GitHub repo. I’ll let you know how it goes.


  1. I do what you describe with Chef, but I use Salt. I haven’t used Chef, but is it really that slow that adding a few dotfiles with simple templating would significantly impact runs? On our Salt highstates I’d estimate it to be on the order of a few milliseconds per user account. Completely negligible. Having my dotfiles in configuration management has been worth its weight in gold since I can just provision a clean vagrant and have it feel like home.

  2. I prototyped one for myself (that does not meet your criteria) based on homesick/homeshick but using Git to store the files in their actual locations. It’s on GitHub if you just want to peek at the idea. It does support multiple repos but doesn’t handle merging them. I could imagine implementing your idea using two branches, one public and one private that you rebase onto the public.

  3. My understanding is that at Etsy it only becomes a problem when people check in really big dotfile collections. oh-my-zsh was specifically mentioned.

  4. I got pointed to this post via a friend because I work on something that may fit your needs. fresh is a tool for “building” your shell configuration (and other config files) from your local files and sourcing files from GitHub.

  5. Clinton Dreisbach

    January 30, 2014 at 9:44 am

    Rafe — I’ve been using dfm for my dotfiles for a while now, and like its simplicity. Particularly, I like that it’s a Perl script that I can put in my dotfiles repo and so I can clone the repo and run one command to set everything up. You can see my dotfiles to see how I have it set up.

  6. Keith M Corbett

    July 16, 2014 at 1:23 am

    +1 for using fresh. Easy to install. Minimal dependencies. Plays nice with git. Scriptable for assembling dot files, .local variations.

    Documentation is… sparse. I wrote a Prezi on “Keeping your dotfiles fresh with Git”.

Leave a Reply

Your email address will not be published.


© 2024 rc3.org

Theme by Anders NorenUp ↑