deezconfigs

Manage deez config files.

deezconfigs will mirror your config files to your $HOME directory (sync) and synchronize them back (rsync). Additionally, you can choose to symlink the files instead (link).

Same idea as GNU Stow or chezmoi, but way simpler, requiring less neuron activation to operate.

Usage

Usage: deez [<options>] <command> [<args>]

Commands:
  sync [<root>|<git>]    Update Home from configs
  rsync [<root>]         Update configs from Home
  link [<root>]          Symlink configs to Home

  status [<root>|<git>]  List files and their status
  clean [<root>|<git>]   Remove all configs from Home

Options:
  -h, --help             Show this message and exit
  -V, --version          Show the version and exit
  -v, --verbose          Show files being copied

[!NOTE]

The "config root" can be any directory containing config files. You should, but are not required to, create a .deez file in the root. This lets deezconfigs know it is safe to use, and lets you run deez from within sub-directories.

$ deez sync
Mirror the files in the current root to `$HOME`.
Also create any missing directories.

$ deez sync ~/myconfigs
Use `~/myconfigs` as the config root.

$ deez sync git:git@github.com:qrichert/configs.git
Sync directly from a Git remote (`https://` works too).

$ deez rsync
Sync files from `$HOME` back into the config root.

$ deez link
Create symlinks in `$HOME` instead of copying the files.
Also create any missing directories.

$ deez --help
For more.

Roadmap

• CLI arguments parsing.
• Command sync.
• Protect $HOME with a .deez file.
• Add --verbose mode (use -V for version).
• Use Git remote as sync root.
• Smart root finder (looks in parents)
• Hooks (pre, post actions)
• Command rsync.
• Command link.
• Command status (with up-to-date status for each file).
• Command clean.
• Push files to a Vec in verbose mode instead of directly printing.
• Pass DEEZ_ROOT and DEEZ_HOME to hooks.
• Refactor tests, there is too much duplication.
• Refactor argument parsing? Maybe?.
• Proper verbose --help section.
• Custom Home directory. Maybe change terminology, Home being the default "target".
• Increase test coverage (features are mostly covered, what's missing are tests for the error cases).
• Perf refactorings for bottlenecks (or for fun).

FAQ

Yet Another Config Manager

I very rarely edit my configuration files. So when I do, I never quite remember how the config manager worked. I wanted a tool so easy that taking 3s to glance at the --help would be enough to remember how to update the configs repo (deez rsync), and mirror the changes to my other environments (deez sync).

That's also why deezconfigs does very little. Instead of making me remberer deez commands, it delegates to tools I use way more often. I much rather nvim or git commit my config files, because those commands are burnt into my muscle memory.

Do I need to use Git?

Not at all. deezconfigs is designed to integrate nicely with Git, but Git is absolutely not a requirement.

Ignore some files

By default, deezconfigs ignores the .git directory at the root, the .ignore and/or .gitignore file at the root (but not elsewhere, although it respects them everywhere), all .deez files, wherever they are (enabling multi-root repos), and the hooks (at the root).

If you want to ignore more files than this, add them to your root .gitignore. Git will let you version the files regardless, just git add -f them.

This, in my mind, strikes a nice balance between configurability and simplicity. You can ignore whatever you want, without squeezing too many heuristics into deezconfigs. It's a Git thing, nothing new to learn.

Copying some files, while linking others

Use mutliple roots. You can have multiple roots (subdirectories) in one repo. Use sync in one, and link in the other.

If you need anything more advanced than that, deezconfigs is likely not the right tool for you.

No templating?

No. It was an idea at first, but hooks are powerful enough to let you do your own templating. It's the same idea as "let Git do its thing". Instead of supporting sub-par templating, deezconfigs defers to hooks. Nothing's stopping you from using a Python script as a hook with some Jinja2 template, or any other language/template engine combination you like.

Unstructured info dump that needs editing

deez requires a .deez file in the config root (or it will ask for confirmation), to prevent yourself from ruining the $HOME directory if ran on the wrong root.

• Respects .ignore and .gitignore files.
• list colors out-of-date files in red (respecting NO_COLOR).
• Smart root finding will be used when 1) no root was explicitly supplied, and 2) the current working directory (default roor) is not a config root (no .deez file). In this case, deezconfigs will look into parent dirs for a .deez file. If one is found, use it as root instead of warning "this is not a deez root".

Hooks

• You can have hooks: pre-sync, post-sync, pre-rsync, post-rsync, pre-link, post-link.
• The extension can be any type of script (it's the file name that counts).
• The script must be executable and must contain a shebang (#!) if not interpretable by sh directly (e.g., python scripts).
• This script will be run through sh: sh -c <root>/<thescript> inside the config root directory.
• Hooks are executed in lexicographic order based on their file name (i.e., post-sync.001.sh will be run before post-sync.002.sh).

deezconfigs provides some basic information to hooks through environment variables:

• DEEZ_VERBOSE Will be true if run in verbose mode, otherwise it will be unset (hint: use [ -n $DEEZ_VERBOSE ] to test for existance).