Context
tests/package/test_java_codebase_rag_cli.py:23 defines an autouse, session-scoped fixture _install_java_codebase_rag_entrypoint that runs:
repo_root = Path(__file__).resolve().parent.parent.parent
subprocess.run([sys.executable, "-m", "pip", "install", "-e", str(repo_root)], check=True, ...)
Its intent is sound: ensure the java-codebase-rag console entrypoint exists for subprocess CLI tests.
Problem
It mutates the shared .venv's editable install unconditionally each session. When two git worktrees (or two sessions) share one .venv and both run the suite, they flip-flop the editable .pth between worktree A and worktree B (last writer wins).
Observed while working in a feature worktree: the worktree's __editable__.java_codebase_rag-0.9.7.pth was silently rewritten to the main-repo src path at a timestamp when no pip ran in the worktree — another session's test run had flipped it. This then broke the worktree's tests/conftest.py::_enforce_editable_install (which requires the jrag entrypoint to resolve under the current repo root) and would make CLI subprocess tests import the wrong source tree.
Options
- Idempotent guard — no-op the fixture when
jrag / java-codebase-rag already resolve under repo_root (skip the reinstall).
- Skip when present — only install if the entrypoint is missing entirely.
- Document "one
.venv per worktree" as the supported layout (simplest, but the fixture still penalizes the common single-checkout case with a per-session reinstall).
Severity
DX / test-infrastructure, not a product-code correctness bug. But it makes concurrent worktree development flaky and surprises anyone sharing a venv across checkouts.
Related
Context
tests/package/test_java_codebase_rag_cli.py:23defines an autouse, session-scoped fixture_install_java_codebase_rag_entrypointthat runs:Its intent is sound: ensure the
java-codebase-ragconsole entrypoint exists for subprocess CLI tests.Problem
It mutates the shared
.venv's editable install unconditionally each session. When two git worktrees (or two sessions) share one.venvand both run the suite, they flip-flop the editable.pthbetween worktree A and worktree B (last writer wins).Observed while working in a feature worktree: the worktree's
__editable__.java_codebase_rag-0.9.7.pthwas silently rewritten to the main-reposrcpath at a timestamp when nopipran in the worktree — another session's test run had flipped it. This then broke the worktree'stests/conftest.py::_enforce_editable_install(which requires thejragentrypoint to resolve under the current repo root) and would make CLI subprocess tests import the wrong source tree.Options
jrag/java-codebase-ragalready resolve underrepo_root(skip the reinstall)..venvper worktree" as the supported layout (simplest, but the fixture still penalizes the common single-checkout case with a per-session reinstall).Severity
DX / test-infrastructure, not a product-code correctness bug. But it makes concurrent worktree development flaky and surprises anyone sharing a venv across checkouts.
Related