My Dotfiles

My dotfile repo has got big and complicated, and I should probably definitely get round to streamlining some of it with ansible. But, there are some things about it that I think are good ideas, that you might be interested in. Check the README on github for the full details.

Firstly, since you’re usually starting on a new machine if you’re installing dotfiles, I include a suite of installation scripts that will configure my machine how I like it. There are scripts for creating development directories I commonly use, installing common packages via apt-get or homebrew, installing my vim plugins, and installing and linking the dotfiles into my home directory.

I store the dotfile repo in a directory called .dofiles within my home directory. I then run a script that links each dotfile in the repo into the correct place, e.g. ~/.dotfiles/vimrc gets linked to ~/.vimrc. I also have a local bin directory in~/bin in my $PATH that contains some useful custom scripts I use a lot.

When it’s an option, I split my config files into logical pieces. For vim, for example, I have

vimrc
vimrc.key-bindings
vimrc.addons
vimrc.local

The local version is useful for configuration options I only want some of the time. Say, for work only, or for macOS only.

I have local files for my aliases, git, bash and zsh rc files too. I do this when the difference between, say the unix and macOS version of a file is consistent and well-understood. I’ll have _unix and _macos versions of the file and link them to the local file.

Testing

New Macs don’t appear on my desk very often, so I don’t run the installation scripts in the real-world enough to be confident that everything still works perfectly 12 months later.

As I’ve mentioned before, I use a quick Docker environment to test my installation and configuration scripts. It’s a quick, hacky way to spin up a disposable test environment.

Tagged: | software-development |
Cover Image: bilge tekin, via Unsplash