Packaging

dootdoot supports source builds, local Cargo installs, and tag-driven macOS release artifacts. The project license is MIT, matching the repository LICENSE and the Cargo package metadata.

Recommended macOS Install Path

After the first tagged release runs, macOS users should install from the custom Homebrew tap:

brew install skeswa/tap/dootdoot
brew upgrade dootdoot

Homebrew is the primary friend-friendly channel because it requires no Rust toolchain and keeps updates on the normal brew update && brew upgrade path.

Installer Script Fallback

Each release also publishes a shell installer for macOS users who do not use Homebrew:

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/skeswa/dootdoot/releases/latest/download/dootdoot-installer.sh | sh

The installer writes into CARGO_HOME and installs the standalone updater:

dootdoot-update

This path is useful for quick bootstrap installs, but Homebrew remains the preferred update channel on macOS.

Local Cargo Install

cargo install --path dootdoot --locked

The install uses committed runtime assets through dootdoot-core; it does not run xtask and does not need network access beyond Cargo dependency resolution.

For a clean local smoke test without writing into the user's normal Cargo bin directory:

scripts/package-smoke
target/cargo-install-smoke/bin/dootdoot --version

Release Automation

Release artifacts are generated by dist (cargo-dist) 0.32.0 from the committed workspace metadata:

• packages = ["dootdoot"] ensures xtask is never shipped.
• targets = ["aarch64-apple-darwin", "x86_64-apple-darwin"] covers Apple Silicon and Intel Macs.
• [workspace.metadata.dist.github-custom-runners] routes both macOS target builds to the dootdoot-macos-arm64 self-hosted Apple Silicon runner; the Intel archive is cross-built there by dist.
• installers = ["shell", "homebrew"] produces dootdoot-installer.sh and dootdoot.rb.
• install-updater = true adds dootdoot-update for shell-installer users.
• github-attestations = true asks GitHub Actions to attest release artifacts.

The generated workflow lives at .github/workflows/release.yml. It runs on pull requests in plan mode and publishes on semver-looking tags such as v0.1.0. dist owns this file — do not hand-edit it; change [workspace.metadata.dist] and run dist generate instead. Action SHA pins are kept durable through [workspace.metadata.dist.github-action-commits].

Cutting a release is automated: dispatch Cut release, merge the version-bump PR, and the tag and publish happen on their own. The full lifecycle, required secrets (RELEASE_TOKEN and HOMEBREW_TAP_TOKEN), and troubleshooting live in releasing.md.

Before the first public release:

1. Create the skeswa/homebrew-tap repository.
2. Add the RELEASE_TOKEN secret (a PAT with contents: write) so the auto-pushed tag triggers the build.
3. Add the HOMEBREW_TAP_TOKEN secret (write access to the tap).
4. Run scripts/release-smoke and dist plan.
5. Tag the current version once by hand (the automation triggers on version changes); every release after that goes through Cut release.

Crates.io

The workspace is ready for package listing checks, but crates.io publication should be a separate release decision because the binary crate depends on the core crate. Publish dootdoot-core first, then publish dootdoot with a versioned dependency on the matching core release.