Files
hermes-agent/hermes_cli
FroRaut d2d45b549b fix(pm): a borrowed HERMES_HOME leaves the source checkout to the root that owns it
Dependency state is scoped per data root (<root>/installs/<key>, and the
store under <root>/tools when the install stamp names no runtimeDir, as
source stamps never do). A launch of a shared checkout under another
root -- a test's temporary HERMES_HOME, a per-task home, a CI service
home -- therefore treated the checkout as a fresh install of its own:
it downloaded a full tool store into that root (~0.5 GB), synced a venv,
then ran the checkout's update tail against the shared tree (launchers
repointed at the temporary interpreter, web/TUI/desktop rebuilt,
install stamp and bootstrap receipt rewritten) under an update lock that
lives in the borrowing home. Deleting the home then bricked `hermes`,
and concurrent borrowers raced each other's product builds (#123238).

pm.environments.owning_home_root() identifies the root that installed
the checkout: the platform default root or the root the checkout sits
in, whichever holds committed state (facts.json) for it, when that state
is not the active root's own (the owner, one of its profiles, or a home
whose installs link back to it). A fresh install and a custom root that
owns its tree resolve to None and keep today's behaviour.

- store_root(): an unstamped store resolves to the owner's tools/, so a
  borrowing launch uses the interpreter the checkout's launchers already
  exec and downloads no tool store of its own. HERMES_RUNTIME_DIR and a
  stamped runtimeDir still win.
- prepare_launch(): a borrowing root syncs its own dependency
  generation, as a process spawned under a live update does, and returns
  its relaunch interpreter. It never arms or runs the tail, never
  publishes launchers and never removes the owner's update markers.

Tests: tests/hermes_cli/test_borrowed_home_launch.py (10). Each half
fails without its change: store_root's two borrowing cases, and the
prepare_launch tail/marker cases.

(cherry picked from commit 8c427c8389634f6cebc3a8ced9a626c6354e8a18)
2026-10-03 22:46:14 -04:00
..
…
…
…
…
…