Repository navigation
Skip Hermes source venvs built for another Python version - #19160
Conversation
The TUI Python wrapper picked $HERMES_PYTHON_SRC_ROOT/{venv,.venv} before
the launcher's own interpreter (#12996). A Hermes source checkout managed by
`hermes pm` runs on a store interpreter, and its .venv can be an unrelated
test env on another Python minor version, so the gateway crash-looped
loading extensions built for the launcher's version.
Resolve the launcher interpreter first, and skip a source venv whose
pyvenv.cfg version differs from it. Venvs without a readable version, or
when the launcher is unknown, are still preferred as before, which keeps
the symlinked-venv fix for #12948.
Fixes #18680
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
All contributors have signed the CLA ✍️ ✅ |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to No concrete merge-blocking issue was established for the supported Hermes invocation. The change is mergeable after normal checks. Pre-merge checks |
|
|
|
|
Subagent review at 840a8d1: merge. Ran tests/test_hermes_wrapper_hooks.py on the head (passes, including the #12948 symlinked-venv case) and with main's wrapper swapped in (the new test fails with the #18680 symptom). pyvenv.cfg parsing falls back to the old venv-first behavior on anything unknown. Follow-up nit: the read loop skips a final line with no trailing newline. |
|
Merge receipt for |
What was wrong
Since #12996,
cmux-hermes-python-wrapperpicked$HERMES_PYTHON_SRC_ROOT/{venv,.venv}/bin/python{,3}before the interpreter that launched Hermes. That fixed #12948: on macOSps commresolves a symlinked venv Python to the base interpreter, which lacks the venv's site-packages. However, a Hermes source checkout managed byhermes pmruns on a store interpreter, and its.venvcan be an unrelated test env on another Python minor version. The gateway then ran on that venv's Python (for example 3.11), Hermes's bootstrap added site-packages built for the launcher's 3.14, and the gateway crash-looped withNo module named 'pydantic_core._pydantic_core'.What changed
ps commof the TUI's parent) first.pyvenv.cfgversion/version_infomajor.minor differs from the launcher's (read with<launcher> -I -S -c ..., only when the launcher's basename looks like Python). A mismatched venv is skipped, and the launcher interpreter is used.pyvenv.cfg, no launcher found), the venv is preferred as before. The Hermes integration: gateway crash-loops when the Hermes venv python is a symlink (cmux-hermes-python-wrapper resolves the base interpreter viaps comm) #12948 case (symlinked uv venv, launcher reported as the framework base Python of the same version) still selects the venv.How tested
test_tui_python_wrapper_skips_venv_for_other_python_versionintests/test_hermes_wrapper_hooks.pyruns the wrapper under a real Python launcher with an intermediate process, matching Hermes's process tree. A.venvwhosepyvenv.cfgnames another version must lose to the launcher, and one naming the launcher's version must still win. The mismatched case fails against themainwrapper (expected the launcher interpreter, got venv).python3 tests/test_hermes_wrapper_hooks.pypasses locally, including the existing Hermes integration: gateway crash-loops when the Hermes venv python is a symlink (cmux-hermes-python-wrapper resolves the base interpreter viaps comm) #12948 symlinked-venv test.Fixes #18680
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by cubic
Fixes Hermes gateway crash-loops (
No module named 'pydantic_core._pydantic_core') when a source checkout's.venvruns a different Python minor version than the launcher. The wrapper now resolves the launcher interpreter first and only prefers the source-root venv when itspyvenv.cfgversion matches the launcher's.ps comm) #12948.Written for commit 840a8d1. Summary will update on new commits.
Note
Medium Risk
Changes TUI gateway interpreter selection in the Hermes launch path; wrong logic could break venv preference on macOS or reintroduce version-mismatch crashes.
Overview
Fixes Hermes TUI gateway crash-loops when a source checkout’s
.venvtargets a different Python minor than the interpreter that launched Hermes (e.g. store Python 3.14 vs an unrelated test venv on 3.11).cmux-hermes-python-wrappernow resolves the launcher interpreter first (viapson the TUI’s grandparent), then still prefers$HERMES_PYTHON_SRC_ROOT/{venv,.venv}only whenpyvenv.cfgmajor.minor matches the launcher (or when either version is unknown). Mismatched venvs are skipped and the launcher is used. Helpers read the launcher version with a short-I -S -cprobe and the venv version frompyvenv.cfgwithout executing the venv.Tests add a Hermes-like process tree and assert mismatched venvs lose to the launcher while same-version venvs still win (preserving the symlinked-venv/macOS behavior from #12948).
Reviewed by Cursor Bugbot for commit 840a8d1. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit
python3as a fallback.