fix: doctor probes backend readiness; install.sh resolves user-scripts dir
test / integration-docker (push) Successful in 20s
prd-number / assign-numbers (push) Failing after 24s
test / unit (push) Successful in 57s
lint / lint (push) Successful in 1m1s
Update Quality Badges / update-badges (push) Failing after 54s
test / integration-firecracker (push) Successful in 5m7s
test / coverage (push) Successful in 27s
test / publish-infra (push) Successful in 2m34s
test / integration-docker (push) Successful in 20s
prd-number / assign-numbers (push) Failing after 24s
test / unit (push) Successful in 57s
lint / lint (push) Successful in 1m1s
Update Quality Badges / update-badges (push) Failing after 54s
test / integration-firecracker (push) Successful in 5m7s
test / coverage (push) Successful in 27s
test / publish-infra (push) Successful in 2m34s
Addresses the third review round on PR #481. - `bot-bottle doctor` now checks `is_backend_ready()` (a full backend status() probe: daemon reachable, network pool present, KVM usable) instead of the cheap PATH-only `is_backend_available()`. A host with a stopped Docker daemon or half-configured Firecracker no longer reports `ok: backend` / exit 0 when `start` can't actually work; each not-ready backend prints its own diagnostics, and doctor passes only if at least one backend is ready. - `install.sh` resolves the pip `--user` scripts directory from the interpreter (`sysconfig.get_path("scripts", get_preferred_scheme("user"))`) instead of hardcoding `~/.local/bin`, which is wrong on a python.org macOS interpreter (`~/Library/Python/<X.Y>/bin`). The PATH guidance now prints the actual directory. Tests: doctor tests mock `is_backend_ready` (the readiness contract) and cover the not-ready → fail path; a new install-script test drives the macOS `osx_framework_user` scheme and asserts it resolves a non-~/.local/bin directory. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit was merged in pull request #481.
This commit is contained in:
@@ -33,7 +33,7 @@ user whether their host is actually ready to run a bottle.
|
||||
`bot-bottle doctor`. It never installs Docker or a VM backend silently
|
||||
and never uses `sudo`.
|
||||
- `install.sh` is idempotent — safe to re-run.
|
||||
- `bot-bottle doctor` reports Python version, backend availability, and
|
||||
- `bot-bottle doctor` reports Python version, backend *readiness*, and
|
||||
config-dir presence, exiting non-zero when a hard prerequisite is unmet.
|
||||
- The package keeps **zero runtime pip dependencies** (stdlib-only,
|
||||
matching the existing constraint in `AGENTS.md`).
|
||||
@@ -129,8 +129,11 @@ A POSIX `sh` bootstrapper that:
|
||||
4. Installs via `pipx` if available, else `python3 -m pip install --user`.
|
||||
The spec defaults to the git URL and is overridable via
|
||||
`BOT_BOTTLE_INSTALL_SPEC` (used by tests / local installs).
|
||||
4. Locates the `bot-bottle` entry point (PATH or `~/.local/bin`).
|
||||
5. Runs `bot-bottle doctor` and reports the result.
|
||||
5. Locates the `bot-bottle` entry point: PATH first, else the
|
||||
interpreter's own user-scheme scripts dir resolved via `sysconfig`
|
||||
(`~/.local/bin` on Linux, `~/Library/Python/<X.Y>/bin` on a python.org
|
||||
macOS interpreter — not hardcoded).
|
||||
6. Runs `bot-bottle doctor` and reports the result.
|
||||
|
||||
It is idempotent and never calls `sudo`.
|
||||
|
||||
@@ -140,10 +143,12 @@ A new store-free subcommand (no DB migration required) that checks and
|
||||
reports:
|
||||
|
||||
- **python** — interpreter version (hard requirement: ≥ 3.11).
|
||||
- **backend** — at least one backend available on this host
|
||||
(macos-container / firecracker / docker), reusing
|
||||
`is_backend_available()` rather than hardcoding Docker, since the
|
||||
default backend is now a VM backend. Hard requirement.
|
||||
- **backend** — at least one backend *ready* on this host
|
||||
(macos-container / firecracker / docker), via `is_backend_ready()` — a
|
||||
full backend `status()` probe (daemon reachable, network pool present,
|
||||
KVM usable), not a PATH-only check: a stopped daemon or half-configured
|
||||
backend must not report `ok` when `start` can't work. Each not-ready
|
||||
backend prints its own diagnostics. Hard requirement.
|
||||
- **config** — whether `~/.bot-bottle/` exists (advisory only; `start`
|
||||
provisions on first run).
|
||||
|
||||
@@ -152,7 +157,8 @@ Exits 0 when both hard requirements pass, non-zero otherwise.
|
||||
## Testing strategy
|
||||
|
||||
- Unit test `bot-bottle doctor` success/failure paths with backend
|
||||
availability and Python version mocked.
|
||||
readiness (`is_backend_ready`) and Python version mocked, including the
|
||||
available-but-not-ready → fail case.
|
||||
- Unit test that `pyproject.toml` parses, declares the entry point and an
|
||||
empty `dependencies` list, and that every `package-data` glob resolves
|
||||
to a file that exists on disk (guards against drift).
|
||||
|
||||
Reference in New Issue
Block a user