Make install work on PEP 668 systems + fix venv MCP-server wiring#54
Merged
Conversation
The flagship one-liner and Quick start both used a global `pip install`, which fails with `externally-managed-environment` on Debian/Ubuntu and other PEP 668 systems — the most common Linux setup. - Flagship one-liner now uses pipx: it installs CodeRAG into an isolated environment and puts `coderag` on PATH, exactly what the agent needs to launch the MCP server. pip + venv shown as the alternative. - Quick start now creates a virtual environment first, and notes the `coderag install` activation footgun: run it via `.venv/bin/coderag` so it records the venv's Python by absolute path rather than a bare `coderag` the agent can't resolve from a normal shell. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F2K45QFkrJEACjmWPwUvqY
`coderag install` recorded a bare `coderag mcp` whenever `coderag` was on PATH at install time — including an *activated* virtualenv, whose `bin/coderag` disappears once deactivated. The agent then launches the server from its own shell and fails to find `coderag`. `_server_invocation` now writes a bare `coderag` only when it is durably on PATH: a non-venv (system/user) install, or a launcher outside the current venv prefix (e.g. a pipx shim in ~/.local/bin). Inside a venv it pins this interpreter's `coderag` console script by absolute path — looked up lexically in sys.executable's bin dir so a venv's `python` symlink is not followed back to the base interpreter — falling back to `<python> -m coderag.surfaces.cli mcp`. pipx and system installs still get a clean bare `coderag`. Adds tests for each resolution case: system install, activated venv, venv-not-activated, pipx shim outside the venv, and the module fallback. Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F2K45QFkrJEACjmWPwUvqY
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The flagship one-liner and Quick start used a global
pip install, which fails witherror: externally-managed-environmenton Debian/Ubuntu and other PEP 668 systems — the most common Linux setup, so nearly every new user hits it. Working around it with a venv then exposed a second, quieter trap incoderag install.What
1. Docs —
README.mdcoderagonPATH— exactly what an agent needs to launch the server. A blockquote covers installing pipx and the plain-pip+ venv fallback for PEP 668.python3 -m venv .venv && source .venv/bin/activate, plus a note on thecoderag installactivation footgun (below).2. Fix —
coderag/install.py(_server_invocation)coderag installrecorded a barecoderag mcpwhenevercoderagwas onPATHat install time — including an activated virtualenv, whosebin/coderagdisappears once deactivated. The agent then launches the server from its own shell and can't findcoderag.Now it writes a bare
coderagonly when it's durably onPATH: a non-venv (system/user) install, or a launcher outside the current venv prefix (e.g. a pipx shim in~/.local/bin). Inside a venv it pins this interpreter'scoderagconsole script by absolute path — looked up lexically insys.executable's bin dir so a venv'spythonsymlink isn't followed back to the base interpreter — falling back to<python> -m coderag.surfaces.cli mcp. pipx and system installs still get a clean barecoderag.Tests
Adds coverage for each resolution case in
tests/test_install.py: system install, activated venv, venv-not-activated, pipx shim outside the venv, and the module fallback.pytest -m "not integration"— green (exit 0)ruff check ./ruff format --check .— cleanmypy coderag— Success, no issues found in 40 source files🤖 Generated with Claude Code
https://claude.ai/code/session_01F2K45QFkrJEACjmWPwUvqY
Generated by Claude Code