Skip to content

fix(update): dependency sync works on pip/site-packages installs — stale VIRTUAL_ENV no longer crashes uv (salvage #83434) - #92824

Merged
teknium1 merged 5 commits into
mainfrom
hermes/hermes-83bfdb1e
Aug 23, 2026
Merged

teknium1 merged 5 commits into
mainfrom
hermes/hermes-83bfdb1e

Conversation

@teknium1

Copy link
Copy Markdown
Collaborator

Summary

hermes update's dependency sync no longer crashes on pip/site-packages installs — when the exported VIRTUAL_ENV points at the nonexistent PROJECT_ROOT/venv (which is never created on those installs), the shared install helper now drops the stale pointer and pins --python sys.executable, so uv installs into the running interpreter instead of refusing with "Failed to inspect Python interpreter from active virtual environment" (salvage of #83434 by @mrmixx-max).

Same bug class already fixed piecemeal at two other sites (#71510 ZIP path, #83335 lazy-deps); this closes the shared helper that the main update path, interrupted-install recovery, and git update path all route through.

Changes

  • hermes_cli/main.py (@mrmixx-max, 2 commits): stale-VIRTUAL_ENV detection in _install_python_dependencies_with_optional_fallback; _is_uv_command (handles python -m uv and launcher wrappers, not just basename); _insert_python_pin (caller-supplied --python wins); Windows shim quarantine retargeted at the pinned interpreter's real Scripts dir (quarantining the nonexistent venv's dir would leave the running hermes.exe locked — the original bug in a different coat).
  • Follow-up (ours): salvaged test fixture accepts the strict_quarantine kwarg the update sync passes since fix(update): a contended Windows venv is never mutated — failed shim quarantine refuses instead of warning (#87331) #92617 (sibling-test blast radius).

Validation

Check Result
Salvaged suite + quarantine-rescue suite 21/21
test_cmd_update.py failure set byte-identical to origin/main (6 pre-existing env reds)
A/B repro, real uv (0.11.19) + real venv + real editable install, same machine: Phase A merge-base → VERDICT: CRASHED ("Failed to inspect Python interpreter…" propagated from real uv) · Phase B PR head, identical scenario → VERDICT: INSTALLED (package imports from the pinned interpreter) proven
A/B falsifiability Phase A's first run legitimately did NOT crash — uv silently falls back to cwd/.venv when one exists; the repro was corrected to the true site-packages layout (no .venv under PROJECT_ROOT), where the bug fires 100%. The gate catching an imprecise repro is the gate working.

Phase-2 salvage queue item 2 (#91277).

Infographic

Pin the interpreter

mrmixx-max and others added 4 commits August 23, 2026 02:01
…ENV is stale

When Hermes is installed via pip / site-packages (e.g. the Windows
installer), PROJECT_ROOT is the interpreter's site-packages directory and
PROJECT_ROOT/venv is never created. The update and interrupted-install
recovery paths still set VIRTUAL_ENV=PROJECT_ROOT/venv, so uv fails with
'Failed to inspect Python interpreter from active virtual environment'
before installing anything — leaving the install partially updated.

Detect the nonexistent VIRTUAL_ENV in the shared dependency-install helper
and pin uv to the running interpreter (uv pip install --python
sys.executable) instead, matching the fix already applied to lazy-deps
(#83335) and the ZIP update path (#71510).
- _is_uv_command: detect 'python -m uv'/'python -m uvx' and launcher
  wrappers, not just a uv basename (review: naive check missed module form)
- _insert_python_pin: never duplicate a caller-supplied --python (review:
  last-wins ambiguity)
- _interpreter_scripts_dir: when pinning to sys.executable on Windows with
  no project venv, quarantine the running interpreter's Scripts dir so the
  hermes.exe shims uv rewrites are actually unlocked (review: quarantine
  path diverged from pinned interpreter)
- tests: rewritten to repo English convention; added python -m uv,
  --python-guard and Windows quarantine-target cases (5 total)
Sibling-test blast radius from #92617: the salvaged fixture's fake
_run_quarantined_install predates the strict_quarantine kwarg the
update sync now passes.
@github-actions

github-actions Bot commented Aug 23, 2026 •

Copy link
Copy Markdown

૮ >ﻌ< ა ci review

ran on 3ca84dc — fix: derive the pinned interpreter's Scripts dir via venv_bi

⚠️ Warnings

OSV vulnerability scan · View job

7 known vulnerabilities found in pinned dependencies.

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.


debug info

CI timings

CI timings · View report · View job

Wall time 2m31s vs 2m42s (-6.8%). 4 job(s) slower, 6 faster, 2 unchanged.

  • OS-specific tests / Windows-only tests: -34.0s
  • OS-specific tests / macOS-only tests: -28.0s
  • OSV scan / Scan lockfiles / osv-scan: +10.0s
  • Python tests / Run tests: +7.0s
  • Detect affected areas: +4.0s

@teknium1
teknium1 force-pushed the hermes/hermes-83bfdb1e branch from b10bbaf to 76c7343 Compare August 23, 2026 09:01
…6105 lint)

The salvaged _interpreter_scripts_dir hand-rolled the Scripts/bin layout,
which the AST lint-test in test_update_zip_two_phase forbids — route it
through the canonical hermes_constants.venv_bin_dir instead, with the
interpreter's own dir as fallback for non-venv layouts.
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists area/install-update Installer, updater, packaging, wheels, doctor platform/windows Native Windows-specific behavior or breakage sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows labels Aug 23, 2026
@teknium1
teknium1 merged commit 5c1a304 into main Aug 23, 2026
37 checks passed
@teknium1
teknium1 deleted the hermes/hermes-83bfdb1e branch August 23, 2026 09:16
teknium1 added a commit that referenced this pull request Aug 23, 2026
The salvaged fix covered the git-path sync; the same raw-os.environ
construction existed at the main update path and the interrupted-install
recovery path. All three now build their uv env via managed_python_env()
(#83914 class — same bug, all sites).

A/B-proven with real uv: poisoned UV_PYTHON/UV_SYSTEM_PYTHON steers the
merge-base construction into the hijacker's interpreter (VERDICT:
HIJACKED); the managed construction installs into the install's venv
(VERDICT: ISOLATED). Compose-checked with #92824's stale-VIRTUAL_ENV pin:
isolation + pin together install into the running interpreter on the
site-packages shape.
melon-xf added a commit to melon-xf/hermes-agent that referenced this pull request Sep 3, 2026
The salvaged fix covered the git-path sync; the same raw-os.environ
construction existed at the main update path and the interrupted-install
recovery path. All three now build their uv env via managed_python_env()
(NousResearch#83914 class — same bug, all sites).

A/B-proven with real uv: poisoned UV_PYTHON/UV_SYSTEM_PYTHON steers the
merge-base construction into the hijacker's interpreter (VERDICT:
HIJACKED); the managed construction installs into the install's venv
(VERDICT: ISOLATED). Compose-checked with NousResearch#92824's stale-VIRTUAL_ENV pin:
isolation + pin together install into the running interpreter on the
site-packages shape.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/install-update Installer, updater, packaging, wheels, doctor comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists platform/windows Native Windows-specific behavior or breakage sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants