Repository navigation
fix(deps): pin graphrag-sdk to <0.9.0 and build image from uv.lock #723
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -36,9 +36,17 @@ RUN apt-get update \ | |
|
|
||
| WORKDIR /app | ||
|
|
||
| # Install Python dependencies | ||
| COPY pyproject.toml ./ | ||
| RUN pip install --no-cache-dir --break-system-packages . | ||
| # Install Python dependencies pinned to uv.lock so the image matches CI. | ||
| # uv is pinned too: it produces the constraints file, so an unpinned | ||
| # upgrade could change `uv export` semantics and break reproducibility. | ||
| # It is removed in the same layer, since only the export step needs it. | ||
| ARG UV_VERSION=0.12.5 | ||
| COPY pyproject.toml uv.lock ./ | ||
| RUN pip install --no-cache-dir --break-system-packages "uv==${UV_VERSION}" \ | ||
| && uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \ | ||
| && pip uninstall -y --break-system-packages uv \ | ||
| && pip install --no-cache-dir --break-system-packages -c /tmp/constraints.txt . \ | ||
| && rm /tmp/constraints.txt | ||
|
Comment on lines
+45
to
+49
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed — RUN pip install --no-cache-dir --break-system-packages "uv==${UV_VERSION}" \\
&& uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \\
&& pip uninstall -y --break-system-packages uv \\
&& pip install --no-cache-dir --break-system-packages -c /tmp/constraints.txt . \\
&& rm /tmp/constraints.txtSaves ~23MB (the Verified in a real image build: |
||
|
|
||
| # Verify Node.js tooling for building the frontend | ||
| RUN node --version && npm --version | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Investigated this one and it turned out to be more than a metadata nit — thanks for pushing on it.
On the README specifically: I tested it, and current setuptools tolerates the missing file (it warns rather than fails), so metadata generation was not actually breaking:
But the underlying concern was real, and worse than fragile metadata. Because
pip install .ran with no sources present,[tool.setuptools.packages.find]matched nothing — so theapipackage, theapi.mcptemplates package-data, and the console scripts never reachedsite-packages. A console script resolves imports from its ownbindirectory rather than the working directory, so both entry points were dead in the image:That means the documented
CGRAPH_MODE=mcppath instart.sh(exec cgraph-mcp) could never have started. Web mode only worked by accident, because uvicorn adds the working directory to the import path.Fix (bbd4118) — took your second suggestion, splitting the install so the dependency layer stays cache-friendly:
Verified on a full build of the real Dockerfile:
Plus runtime smoke tests of both modes:
Application startup complete,GET /api/list_reposreturns200 {"status":"success","repositories":[]}, andGET /serves the SPA with200CGRAPH_MODE=mcpnow answers a JSON-RPCinitialize, returningserverInfo.name = "code-graph"No regression to web mode:
STATIC_DIRstill resolves against/app/api, because the working directory takes precedence oversite-packageson the import path.