chore(deps): fix dependency resolution for unsupported Python versions#32
Conversation
- Cap requires-python to <3.14 to avoid resolution failures for packages without 3.14 support - Remove uv.lock since it is unnecessary for a library project - Remove invalid exclude-newer = "7 days" from [tool.uv] Made-with: Cursor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughUncommented Changes
Sequence Diagram(s)(omitted — changes do not introduce a new multi-component sequential flow warranting a diagram) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
Containerfile (1)
17-23: Layer caching optimization pattern is valid but fragile.The two-stage install pattern is a recognized Docker optimization:
- Install dependencies against stub package (layer cached until pyproject.toml changes)
- Copy source and reinstall with
--no-depsThis works correctly because dependency resolution reads from
pyproject.toml, not from Python imports in__init__.py.However, consider these edge cases:
- Dynamic version: If using
dynamic = ["version"]with a version read from source files, the first install may fail or use wrong metadata- Build hooks: Custom build backends that introspect source code would break
- Non-.py package data: Files like
py.typedor data files won't exist during the first installIf the project uses standard static metadata, this should work fine. Consider adding a comment explaining the caching strategy for future maintainers.
📝 Suggested documentation comment
COPY pyproject.toml README.md LICENSE ./ +# Create stub package structure for dependency caching. +# Dependencies are resolved from pyproject.toml, not source imports. RUN mkdir -p src/cordon && touch src/cordon/__init__.py RUN CMAKE_ARGS="-DGGML_VULKAN=on" \ uv pip install --system ".[llama-cpp]" COPY src/ ./src/ +# Reinstall package with actual source; --no-deps skips dependency re-resolution RUN uv pip install --system --no-deps .🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Containerfile` around lines 17 - 23, Add a brief comment above the two-stage install RUN commands (the layer-caching pattern that first runs `uv pip install --system ".[llama-cpp]"` before copying `src/` and running `uv pip install --system --no-deps .`) explaining that this optimizes Docker layer caching by installing dependencies from static pyproject.toml metadata, and call out known caveats: it breaks if metadata uses `dynamic = ["version"]` sourced from code, if custom build hooks inspect source, or if package data (e.g. py.typed or other non-.py files) is required during the first install; recommend removing the optimization when any of those conditions apply.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@Containerfile`:
- Around line 17-23: Add a brief comment above the two-stage install RUN
commands (the layer-caching pattern that first runs `uv pip install --system
".[llama-cpp]"` before copying `src/` and running `uv pip install --system
--no-deps .`) explaining that this optimizes Docker layer caching by installing
dependencies from static pyproject.toml metadata, and call out known caveats: it
breaks if metadata uses `dynamic = ["version"]` sourced from code, if custom
build hooks inspect source, or if package data (e.g. py.typed or other non-.py
files) is required during the first install; recommend removing the optimization
when any of those conditions apply.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6cc6d3ce-8a01-4ce1-81eb-3af9ab7f110b
📒 Files selected for processing (3)
.github/workflows/ci.ymlContainerfilepyproject.toml
🚧 Files skipped from review as they are similar to previous changes (1)
- pyproject.toml
- Add Python 3.14 to CI test matrix and bump requires-python to <3.15 - Bump litellm to >=1.83.0 for Python 3.14 compatibility - Upgrade container base image from python:3.11-slim to python:3.13-slim - Optimize Containerfile layer caching by installing deps before copying source - Eliminate redundant llama-cpp-python compilation by building with Vulkan in a single step
|
1 participant
Description
Fix UV dependency resolution failures caused by unsupported Python version splits and remove unnecessary lock file artifacts.
Type of Change
Changes Made
requires-pythonto<3.14to avoid resolution failures for packages without Python 3.14 supportuv.locksince it is unnecessary for a library projectexclude-newer = "7 days"from[tool.uv](expects an absolute RFC 3339 date, not a relative string)Testing
pytestand all tests passChecklist
pre-commit run --all-filesand fixed any issuesAdditional Notes
The
requires-python = ">=3.10"constraint was unbounded, causing UV to resolve dependencies for all Python versions including 3.14+. Since packages likelitellmdon't publish 3.14-compatible builds yet, this caused unsatisfiable dependency errors. Capping at<3.14resolves this until ecosystem support catches up.Summary by CodeRabbit