trust-the-container

name	trust-the-container
description	Don't probe inside the bar-dev distrobox container for things `dev.Containerfile` is supposed to install. Use this when touching `setup.sh`, `dev.Containerfile`, or distrobox-related plumbing — it explains why we removed several layers of "diligent" if-statements and what to do instead.

Trust the container

dev.Containerfile is the single source of truth for what's in bar-dev. Once cmd_setup_distrobox has built and created the container, every binary listed in the Containerfile is there. Probing for those binaries from setup.sh is unnecessary diligence: it adds friction, drifts from the Containerfile, and makes failures less informative, not more.

Rules

1. No command -v X checks against the container's contents. If dev.Containerfile says dnf install watchman, watchman is in the container. Don't distrobox enter -- command -v watchman to confirm. Don't print a [warn] if it's missing.
2. No "stale container, rebuild" self-heal logic. setup::init already calls cmd_setup_distrobox unconditionally; that recipe always rebuilds against the current Containerfile. Adding a second rebuild path inside ensure_* helpers is duplicate plumbing.
3. No existence check before distrobox stop / rm. Both are idempotent and silent on absence with --yes + >/dev/null 2>&1. The "already exists, recreating" warn was a UX wart; the fix was to drop the check, not gate it.
4. Use /usr/bin/<name> paths in distrobox-export. When the package manager controls install location, use the path it writes to. Don't to discover it at runtime.