Dotfile design #
Purpose #
This is a repo for my personal settings and dotfiles, so I can keep them in sync across machines, and keep track of the changes that I make.
What does it do? #
Core Layer #
The core requirements of the repo, and things it absolutely must do:
| Requirement | Descripton |
|---|---|
| Organization | Place dotfiles, settings, and other files into the user's home directory declaratively. |
| Reproducibility | When these files and settings are put in place, all machines should be in as close of a state as possible to each other. |
| Change tracking | All changes need to be tracked, and be able to be reset. Documentation around changes is encouraged. (See Practical Layer) |
| Syncing | The whole repo must sync through a remote git forge, so it is kept current. |
These Core things that the repo does are the basic functions, and without them in some form, the repo is considered broken.
Practical Layer #
This layer of requirements are practical considerations, and things that are good to have. Not quite mission critical, but very important.
| Requirement | Description |
|---|---|
| Chain of Decisions | The repo would preferably document the reasons for changes, either in commit messages or explicit documentation pages. |
| Documentation | While no substitute for the documentation of the tools themselves, common use cases, and repeated commands being documented here would be beneficial |
| Automation | The tools used here would ideally be automatic, as much as is reasonably possible, and remove the need for continual fiddling. |
| Secret storage | If I am saving and sending sensitive, or copyright material as part of this repo, they should be encrypted securely, with minimal fiddling. |
Not all of these are implemented currently, and the repo can function with this state, though it would be considered incomplete.
Extended Layer #
This layer marks the step in to "nice to have", or not yet urgently needed.
| Requirement | Description |
|---|---|
| New machine deployment | An extended use for the repo is to deploy a new machine, and have scripts and hooks ready to run and place extra bits of config that would make it as close to operational as possible. |
| Profiles | As part of new machine deployment, profiling machines would be possible to reflect different OS'es/distros, different roles, and different personas. |
| Full ergonomics and automation | This repo is customized to make it easy to work on, and update. It is automatic as much as possible, capturing changes, or updates from other machines. |
At this point, I wouldn't be worried about new machine setup, because I know there's not significant drift allowed.
Technology #
This is what is currently being used to facilitate the dotfiles:
- Chezmoi: This is the orchestration and placement layer. It handles put files into place, tracking them, and the minimal setup automation that exists.
- Jujutsu: The VCS and sync layer for the repo. I'm testing this over git at the moment, and I like it so far.
- Tangled.org: The current remote host. Again, testing this over GitHub, we'll see how it goes.
Structure #
We're using chezmoi's general structure, though the chezmoi root has been moved to ./home to keep the root clean, and allow for storaging meta info in the root folder. Inside ./home, there are folders with chezmoi's name schema for .config, .local, and others. .symlinks holds the symlinked files that get put into place using chezmoi templates.
Current Issues #
Organization, Change tracking, and Syncing are mostly fine, but the Reproducibility is lacking. In the Practical Layer, only the Chain of Decisions has been remotely touched. I want to get the repo into practical shape by:
- Making sure that all the dotfiles I want to be tracked, are tracked.
- Implementing hooks to track changes to the installed packages, and track symlinked files properly.
- Adding shell scripts and aliases to make working with chezmoi less than totally miserable.
- Fill out the steps to set up a new machine into init scripts that work.
- Add secret management for SSH config, fonts, and sensitive data.
Future Plans #
I want to move the tech stack off of chezmoi and onto a personal config generator, based on nickel (from Tweag), and use that as a robust core for system config and management, tying into my other major prospective projects.