Feature Request: Tool & Package Backup and Restore (dwell setup)

[grave0x]

Summary

Add a dwell setup command that backs up all currently installed tools and packages on the current system, and can reinstall them on a fresh machine. Combines the existing dwell deps scan data with full system package enumeration to create a portable restore plan.

Motivation

Currently dwell deps scan only detects dependencies referenced by the managed dotfiles. But a full machine restore needs more:

• System packages installed via apt/pacman/brew that are not referenced by any dotfile (build tools, media codecs, drivers)
• Cargo-installed tools (cargo install --list)
• Go tools (~/go/bin/)
• pipx-installed Python tools
• npm/yarn global packages
• Flatpak / Snap packages
• Manual binaries in ~/bin/ or /usr/local/bin/ from GitHub releases
• Non-dotfile configuration (app data, browser profiles)

Proposed design

dwell setup capture

dwell setup capture                    # Full system capture to .dwell/setup/
dwell setup capture --no-sys-packages  # Skip system package enumeration
dwell setup capture --output ~/backup  # Custom output directory

Captured structure:

.dwell/setup/
├── sys-packages/              # One file per backend
│   ├── apt.txt                # dpkg -l | grep ^ii | awk '{print $2}'
│   ├── pacman.txt             # pacman -Qq
│   ├── brew.txt               # brew list --formula -1
│   └── nix.txt                # nix profile list
├── language-tools/
│   ├── cargo.txt              # cargo install --list (user-installed)
│   ├── go.txt                 # ls ~/go/bin/
│   ├── pipx.txt               # pipx list --short
│   ├── npm-global.txt         # npm ls -g --depth=0 --parseable
│   └── flatpak.txt            # flatpak list --app --columns=application
├── manual/
│   ├── bin-list.txt           # ls -1 ~/bin/ /usr/local/bin/ (non-distro)
│   └── notes.md               # User notes about manual install steps
├── config/
│   └── paths.yaml             # Non-dotfile config paths to preserve
└── manifest.yaml              # Timestamps, hostname, OS, kernel

dwell setup restore

dwell setup restore                    # Full restore from .dwell/setup/
dwell setup restore --sys-packages     # Only system packages
dwell setup restore --language-tools   # Only language-specific tools
dwell setup restore --interactive      # Ask before each step

Restore flow:

1. Install system packages via apt/pacman/brew
2. Install language tools via cargo install, pipx, npm -g
3. Copy manual binaries from backup
4. Copy config files from backup

dwell setup diff

dwell setup diff              # Compare current vs captured state

Shows:

• Packages installed now but not in backup ("new")
• Packages in backup but not installed now ("missing")
• Version mismatches

Integration with existing features

• Reuses dwell deps scan data to filter dotfile-relevant vs system-level
• Reuses dwell package backends (apt, pacman, brew, nix) for system package operations
• Works alongside dwell sync to version-control the setup directory

Implementation notes

• Capture is read-only — never modifies system state
• Each capture file is a simple newline-separated list (one tool per line)
• manifest.yaml includes: capture date, hostname, OS, kernel version, backend availability
• Restore should be idempotent — skipping already-installed packages
• Language tool installers may need cargo, pipx, npm available first
• Manual binary list in ~/bin/ should be diffed against known package-manager installs

Acceptance criteria

• dwell setup capture creates .dwell/setup/ with package lists
• dwell setup restore reinstalls all captured packages
• dwell setup diff shows drift between captured and current state
• dwell setup capture --no-{sys,lang,manual} granular control
• Restore is idempotent (safe to run multiple times)
• Integration tests verify capture -> restore cycle in CI

[grave0x]

Additional requirements

Cross-system package manager detection

When restoring on a different system than the capture source:

• Auto-detect the available package manager on the current system
• If the backup was created on a different distro (e.g. captured on Arch → restoring on Debian), prompt the user before attempting package installation
• Map common package names across backends where possible (e.g. pacman -S neovim ≈ apt install neovim)
• If the cross-system mapping is ambiguous, list the unmapped packages and ask the user to review

New package manager backend: apk (Alpine Linux)

Add apk as a supported backend:

Operation	Command
Availability	apk --version
List installed	apk info --installed
Install	apk add <package>
Remove	apk del <package>
Search	apk search <query>

Register in PackageManagerRegistry alongside the existing five backends.

Restore flow for cross-system

Capture on Arch (pacman backend)
    │
    ▼
Restore on Debian (apt detected)
    │
    ├── "Backup captured with pacman. Debian uses apt. Attempt cross-install?"
    │       ├── Yes → try `apt install <each package>`
    │       └── No  → save unmapped list, skip
    │
    ▼
Report: N installed, M skipped (not found), X not attempted

Acceptance criteria additions

• apk backend is registered and auto-detected on Alpine
• Cross-system restore prompts user before attempting different backend
• Known package name mappings are applied where unambiguous
• Unmapped packages are reported and skipped, not silently dropped