Modular Dotfiles Collection

Overview

This repository contains a selected subset of my modular dotfiles and configuration, managed by 0k-cfg. Each directory is a self-contained charm (module) that manages configuration for a specific tool or service.

Note: This is not my complete configuration. Only modules suitable for public sharing are included here. Some modules have been excluded because they contain personal settings, are not clean enough yet, or configure tools I no longer actively use.

This repository is intended to be shared publicly. It must never contain sensitive information such as passwords, API keys, private keys, or personal data.

Quick Start

Prerequisites

Install the required dependencies:

## Shell libraries (from https://deb.kalysto.org/)
cat <<EOF | sudo tee /etc/apt/sources.list.d/kalysto.org.list
deb https://deb.kalysto.org no-dist kal-alpha kal-beta kal-main
EOF

wget -O - https://deb.kalysto.org/conf/public-key.gpg | sudo apt-key add -
sudo apt-get update

## Required packages
sudo apt-get install ripgrep plocate

Clone the required repositories:

mkdir -p ~/dev/sh
git clone <0k-cfg-repo> ~/dev/sh/0k-cfg
git clone <kal-shlib-common-repo> ~/dev/sh/kal-shlib-common

Link the cfg command:

mkdir -p ~/.local/bin
ln -sf ~/dev/sh/0k-cfg/src/bin/cfg ~/.local/bin/

Ensure ~/.local/bin is in your PATH.

Deploying a Module

To deploy a configuration module:

cfg setup <module-name>

For example:

cfg setup tmux          # Deploy tmux configuration
cfg setup bash          # Deploy bash configuration
cfg setup alacritty     # Deploy alacritty configuration

Module Structure

Each module follows this structure:

module-name/
├── metadata.yml      # Linking rules and dependencies
├── hooks/
│   ├── setup         # Executed after linking
│   └── install       # Pre-requisite checks
├── src/              # Config files (symlinked per metadata.yml)
├── bin/              # Executables (auto-linked to ~/.local/bin/)
├── share/            # Shared data (auto-linked, see below)
└── relations/        # Cross-module integration files

Automatic Linking

Beyond metadata.yml rules, cfg automatically links certain directories:

Source	Destination	Notes
bin/*	~/.local/bin/
share/fonts/*	~/.local/share/fonts/
share/applications/*	~/.local/share/applications/	Runs update-desktop-database
share/icons/*	~/.local/share/icons/
share/systemd/user/*	~/.local/share/systemd/user/	Auto-enables and starts services

The metadata.yml File

Defines how src/ files are symlinked:

links:
  src:
    .: .config/tmux                    # Link entire src/ to ~/.config/tmux
    bashrc.d/*: .config/bash/bashrc.d/ # Glob patterns supported
    config.ini: /etc/myapp/config.ini  # Absolute paths for system files

dirs:
  ~/.local/share/myapp: 755            # Create directories with permissions

provides:
  bash-shell:                          # Declare provided capabilities

uses:
  ssh-client:
    constraint: required               # Declare dependencies

Key Modules

Module	Description
bash	Shell configuration with modular initialization
tmux	Terminal multiplexer configuration
alacritty	GPU-accelerated terminal configuration
kitty	Terminal emulator configuration
ssh-agent	SSH key management with live-profile integration
live-profile	Dynamic environment variable injection system
git	Git configuration
fonts	Custom fonts
claude	Claude Code AI assistant configuration

Advanced Features

Per-Host Configuration

Several modules support hostname-based variants for machine-specific settings:

• alacritty/src/host/{hostname}.toml
• bash/src/bashrc.d/host/${HOSTNAME}/

Bash Initialization Order

The bash module uses numbered scripts in bashrc.d/ for ordered loading:

Range	Purpose
00-09	Terminal/early setup
10-19	Environment variables
20-29	Completion, shell options
30-39	Prompt configuration
80-89	Editor settings, aliases
90-99	External tools (nvm, pyenv, fzf)

Disable a script by adding .disable extension.

Relations (Cross-Module Integration)

When a module needs to provide configuration or integration for another module, it uses the relations/ directory:

module-name/
├── relations/
│   └── other-module/     # Files specific to other-module integration
│       └── config-file
└── hooks/
    └── other-module-relation-joined  # Executed when both modules are deployed

The hooks/<other-module>-relation-joined script is executed when both the current module and <other-module> are deployed. In these scripts, $PWD is set to the charm root directory.

Example:

#!/bin/bash
set -eu

TARGET="$HOME/.config/other-module/config.conf"
SOURCE="$PWD/relations/other-module/config.conf"

ln -sf "$SOURCE" "$TARGET"

Live-Profile System

The live-profile module provides dynamic environment injection at command execution time via compiled C shims. This enables runtime reconfiguration without restarting long-running processes (e.g., Emacs).

Modules integrate by placing scripts in relations/live-profile/.

Thoughts and Notes

Different installation patterns exist:

• System install (e.g., apt-get install plocate)
• Compiled separate versions (/opt/apps/*)
• Dev versions (links from ~/.local/bin to ~/dev/...)
• Versions bundled in cfg-store (e.g., nvim/app)

Currently no unified way to list, install, or switch between different versions.