fix(config): add --clear flag to uv venv rebuild to prevent Windows bricking #37881#38051
fix(config): add --clear flag to uv venv rebuild to prevent Windows bricking #37881#38051kyssta-exe wants to merge 1 commit into
Conversation
When shutil.rmtree fails to fully remove the old venv (e.g., on Windows where the running interpreter locks files), uv venv without --clear would refuse to overwrite the leftover directory, leaving a half-deleted venv that bricks the CLI. Adding --clear to the uv venv command ensures it handles existing directories gracefully, even if shutil.rmtree partially failed. Fixes NousResearch#37881
`hermes update` can brick a Windows install. cmd_update guards against
concurrent hermes.exe processes and exits, but `hermes update --force` skips
that guard (and the guard's own message tells the user to pass --force).
Forced past it, rebuild_venv runs while the venv is still in use:
shutil.rmtree(venv_dir, ignore_errors=True) # deletes site-packages +
# certifi, fails on the
# locked python.exe ->
# half-gutted venv
uv venv ... (no --clear) # aborts "directory already
# exists" -> never recreated
The venv is left with no pyvenv.cfg; every later HTTPS call dies with
FileNotFoundError (missing cacert.pem) and there is no recovery.
Move the old venv aside atomically with os.replace instead of deleting it in
place, pass --clear, and restore the moved-aside venv if the rebuild fails.
Verified on Windows 11: os.replace of a venv whose interpreter is live
succeeds (Windows tracks a running .exe by handle), so the rebuild actually
completes while the running gateway keeps using the moved-aside copy until it
restarts -- the update succeeds instead of bricking. If the venv genuinely
cannot be moved, the rebuild aborts cleanly and leaves it fully intact.
Root-cause fix for NousResearch#37881. The --clear-only approaches in NousResearch#37895 / NousResearch#38051
don't cover the real lock scenario: when the locked interpreter is inside the
venv being rebuilt, neither rmtree nor `uv venv --clear` can delete it.
- hermes_cli/managed_uv.py: atomic move-aside + --clear + restore-on-failure
- tests/hermes_cli/test_managed_uv.py: in-use venv left intact with no rebuild
attempted; failed rebuild restored; success path asserts --clear
- website/docs/getting-started/updating.md: document --force venv-rebuild safety
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks for the sharp diagnosis here — your root-cause writeup (locked This is now fixed on main via #38887, which independently landed the same Closing as merged via #38887. Appreciate the contribution! |
|
Closing as already fixed on The Windows venv brick (#37881) was fixed in c136eb4 ("fix(update): harden venv rebuild + verify core deps after install"), which uses the same Thanks for the clean fix and the precise root-cause writeup — you correctly diagnosed the locked- |
Summary
When
hermes updatetriggers a venv rebuild on Windows, the runningpython.exeinside the venv is locked by the OS, soshutil.rmtree()silently fails to fully remove the directory. The subsequentuv venvcommand then fails withA directory already exists, leaving the venv in a half-deleted state (pyvenv.cfggone,python.exestill present) which bricks the CLI withModuleNotFoundError.Fix: Adding
--clearto theuv venvcommand makes it handle any leftover directory gracefully, recreating the venv even if the previousshutil.rmtreecall was only partially successful.Changes
hermes_cli/managed_uv.py: Add--clearflag touv venvcommand inrebuild_venv()Testing
Verified locally that:
rebuild_venv()returnsTruewith the--clearflag presentrebuild_venv()returnsFalseonuv venvfailure (unchanged behavior)shutil.rmtreefails (Windows scenario)Related
hermes updatebricks the install on Windows — venv rebuild leaves a venv with nopyvenv.cfg, thenModuleNotFoundError: hermes_cli#37881