caldav cannot install radicale on macOS, and retries forever

Confirmed on macbookpro (macOS 26.6.2): four boots, four identical failures.
caldav's manifest declares apt/pacman/dnf and no brew, so the installer falls
back to the binary name — and radicale is not a Homebrew formula at all, it is
a Python app (pipx/uv). There is nothing correct to put in a brew field, which
is the real gap: PackageManager has no pipx member and osDependencies has no
way to say "unavailable on this platform", so the choice is a wrong guess
retried every boot or silence.

Also recorded, as a NON-bug, because it looked like the real failure and was
already over: the motion/react resolve error appeared on exactly one boot, when
m3e-canvas landed before plugins/node_modules/motion existed. Verified on the
machine — motion is installed and import('motion/react') resolves with 398
exports, and the current boot builds cleanly.

The gap that one exposes is still real: installNpmDependencies is called only
from the install flow, never at boot, so a plugin that arrives without that
flow completing leaves every boot failing a rebuild with "Maybe you need to bun
install" and nothing that ever will.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: f7a62308-0977-4cf4-aa29-c020853fd420

todo/known-bugs/radicale-cannot-be-installed-on-macos.md

@@ -0,0 +1,54 @@
+---
+id: known-bugs/radicale-cannot-be-installed-on-macos
+title: 'caldav retries `brew install radicale` on every boot, and there is no such formula'
+theme: known-bugs
+status: open
+created: 2026-09-22
+date_source: stated
+order: 8
+---
+
+**On macOS, caldav fails its own dependency install on every single boot**, logging a line that reads like
+a transient error and is permanent:
+
+```
+[caldav] radicale install failed (exit 1): … Warning: No available formula with the name "radicale".
+```
+
+Confirmed on `macbookpro` (macOS 26.6.2) 2026-09-22 — four consecutive boots, four identical failures.
+
+**Two things are wrong and only one is caldav's.** `plugins/caldav/manifest.ts` declares
+`packages: { apt, pacman, dnf }` with **no `brew` entry**, so the installer falls back to the binary name
+and runs `brew install radicale`. And the fallback cannot succeed anyway: **radicale is not a Homebrew
+formula.** It is a Python application, installed with `pipx install radicale` or `uv tool install radicale`.
+Homebrew's suggestion in the log — "Did you mean radicle or cadical?" — is two unrelated projects.
+
+So the manifest has nothing correct to put in a `brew` field, which is the actual gap:
+`PackageManager` is `'apt' | 'pacman' | 'dnf' | 'brew'` (`plugins/manifest.ts`). There is no way to express
+"this comes from pipx", and no way to say "not available on this platform" — so the only outcomes are a
+wrong guess retried forever, or silence.
+
+Consequences, in order of how much they matter: caldav does not work on that machine at all (no calendars,
+no contacts — the manifest's own `reason` says so); the failure repeats every boot with no backoff and no
+memory; and the log line is indistinguishable from something worth chasing, which is how it cost a
+debugging session that had been opened about something else entirely.
+
+Worth deciding rather than patching: either `PackageManager` grows a `pipx`/`uv` member, or
+`osDependencies` grows a way to declare a platform where a binary is genuinely unavailable, so the
+installer can say it once and stop.
+
+---
+
+**Found alongside, and NOT a bug — recorded so the next person does not chase it.** The same log carried
+`[plugins] frontend rebuild failed: ResolveMessage: Could not resolve: "motion/react"`, which looked like
+the real failure and was already over. It appeared on exactly one boot: the m3e-canvas plugin had landed on
+disk before `plugins/node_modules/motion` existed. Verified on the machine afterwards — `motion` is listed
+in the generated `plugins/package.json`, installed, and `import('motion/react')` resolves with 398 exports;
+the current boot rebuilds cleanly.
+
+**The gap it exposes is real even though it healed.** `installNpmDependencies` is called from exactly one
+place, `plugins/install.ts`, the install flow. Boot (`plugins/mount.ts`) rebuilds the plugin frontend and
+never installs anything. So a plugin that reaches `plugins/` without that flow completing — cloned by hand,
+or an install interrupted — leaves every subsequent boot failing the rebuild with a message that says
+_"Maybe you need to bun install"_ while nothing ever will. Here the install finished and the next boot was
+fine; on a machine where it does not, the platform cannot recover on its own.