Feature Request: Auto-detect dotfile dependencies and bundle custom tools

[grave0x]

Summary

Add a system that automatically detects required tools, sourced scripts, and external dependencies for each dotfile. Dependencies are listed in a metadata manifest, and any custom/binaries not available via system packages are collected into a portable zip bundle with extraction paths.

Motivation

When restoring dotfiles on a new machine, you need to know what tools each config file depends on. Currently users must manually track things like:

• ~/.bashrc sources ~/.config/fish/config.fish — requires fish to be installed
• ~/.config/nvim/init.lua requires neovim, ripgrep, fd, a Nerd Font
• ~/.config/hypr/hyprland.conf requires hyprland, waybar, wofi, dunst
• Custom scripts in ~/bin/ need to be copied manually
• Binary tools downloaded from GitHub releases have no install record

Proposed design

1. Dependency manifest (.dwell/deps.toml)

A metadata file stored alongside each dotfile in the source directory:

# dwell deps — auto-detected and manually curated dependencies
[deps."dot_bashrc"]
requires = ["bash"]                          # packages needed
sources = ["dot_config/fish/config.fish"]     # other dwell entries this sources
tools = ["starship"]                         # additional packages/tools

[deps."dot_config/hypr/hyprland.conf"]
requires = ["hyprland", "waybar", "wofi", "dunst", "kitty"]
sources = []
tools = []                                    # packages managed by dwell package backends

[deps."dot_config/nvim/init.lua"]
requires = ["neovim"]
sources = ["dot_config/nvim/lua/**"]
tools = ["ripgrep", "fd", "nerd-fonts"]       # may need custom install

2. Auto-detection

dwell deps scan should analyze each dotfile for:

• Shebangs (#!/usr/bin/env bash, #!/usr/bin/python3) → detect required interpreters
• source / . calls in shell scripts → list sourced dwell entries
• require() calls in Lua/Neovim configs
• import statements in Python/PowerShell
• Binary names in shell aliases, PATH references, command -v checks
• exec / run / cmd references to external programs

3. Bundle custom tools (dwell deps bundle)

For tools not available through package managers:

dwell deps bundle --output ~/dotfiles-bundle.zip

This should:

• Scan deps.toml for tools marked as custom
• Lookup known download URLs (or prompt the user)
• Download binaries or collect from local cache
• Zip them with a manifest of extraction paths

# bundle-manifest.yaml inside the zip
tools:
  - name: lazydocker
    version: 0.23.1
    url: https://github.com/jesseduffield/lazydocker/releases/download/v0.23.1/lazydocker_0.23.1_Linux_x86_64.tar.gz
    extract_to: /usr/local/bin
    binary: lazydocker
  - name: nerd-fonts
    version: 3.2.1
    url: https://github.com/ryanoasis/nerd-fonts/releases/download/v3.2.1/FiraCode.zip
    extract_to: ~/.local/share/fonts

4. Restore flow

On a new machine:

dwell init --clone <repo>
dwell deps install     # install required packages via available backends
dwell deps bundle      # extract bundled tools to correct paths
dwell apply            # deploy dotfiles

Implementation notes

• Store deps.toml in the source root (not in user home)
• Auto-detection is best-effort — users can manually edit deps.toml to add/override
• Bundle step should use the age secret backend for any credential files
• Consider adding a dwell deps audit command to detect missing tools on the current system

Acceptance criteria

• dwell deps scan auto-generates deps.toml from existing dotfiles
• dwell deps install reads deps.toml and installs via package backends
• dwell deps bundle creates a portable zip of custom tools
• dwell deps install --bundle installs both packages and bundled tools
• Integration tests cover scan → bundle → restore cycle