chore: migrate from Poetry to uv (closes #105)#230
Conversation
Issue #105 has been open since 2022, originally about consolidating onto Poetry-only. With uv 0.11.13 mature and 10-30× faster than Poetry, the calculus shifted. Migrate the entire dev/CI/Docker toolchain to uv in one pass. Why uv now: - 10-30× faster resolve (matters most across the Py 3.10-3.14 CI matrix) - PEP 621 [project] + PEP 735 [dependency-groups] native (standards-track, not Poetry-specific) - Single binary replaces Poetry's role for install/lock/sync/run - Build backend stays poetry-core>=2.1.3; poetry-core 2.x reads PEP 621 natively, so PyPI publish (`python -m build`) keeps working unchanged Migration scope (one-pass per the matrix-audit-fix-in-one-pass methodology from PR #225 / PR #210): pyproject.toml - [tool.poetry.*] sections → PEP 621 [project] + [dependency-groups.dev] - caret constraints (^X.Y.Z) → PEP 440 explicit ranges (>=X.Y.Z,<(X+1).0.0) - ruff added to dev group (was previously installed ad-hoc in CI) - pytest-runner dropped (deprecated, no longer needed) Lockfile transition - Generated fresh uv.lock (33 packages resolved in 642ms) - Verified resolution parity vs poetry.lock: no major-version drift on any direct dep; only minor/patch bumps within constraints - Deleted poetry.lock; removed uv.lock from .gitignore CI workflows - python-test-versions.yml: snok/install-poetry → astral-sh/setup-uv@v8.1.0 (SHA-pinned), poetry install → `uv sync --locked --dev`, all `poetry run` → `uv run`. Added `enable-cache: true`. - py-to-exe.yml: same pattern. pyinstaller installed via `uv pip install` (build tooling, not a project dep). - python-publish.yml: unchanged (already uses `python -m build`). Dockerfile - pip install poetry → COPY --from=ghcr.io/astral-sh/uv:0.11.13 (tag+digest pinned, same pattern as the python:3.14-slim base). - Multi-stage layout: deps layer (`uv sync --no-install-project --no-dev`) separated from project layer for better cache hit rate. - ENTRYPOINT keeps `python -m proxybroker` via PATH=/app/.venv/bin. Docs - README "Development Setup": Poetry → uv (with `curl install uv` snippet for new contributors); Development Tools list updated. - CLAUDE.md "Setup" + "Known Quirks" sections: Poetry → uv; clarified that poetry-core remains the build backend. Verification (all green locally before push): - uv lock: 33 packages, 642ms - uv sync --locked --dev: succeeds - uv run pytest -x: 293/293 passing - uv run ruff check . + ruff format --check .: clean - python -m build: sdist + wheel both build (validates poetry-core 2.x reading PEP 621 metadata) - docker build + docker run --rm proxybroker2:uv-test --help: image builds in ~4s, CLI invokes correctly Out of scope: - docs/requirements.txt: used directly by ReadTheDocs, not part of dev workflow. Left as-is. - MANIFEST.in: setuptools artifact, no change. - .pre-commit-config.yaml: uses ruff/bandit standalone, no change. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request migrates the project from Poetry to uv for package management, updating the Dockerfile, development documentation, and pyproject.toml to use PEP 621 and PEP 735 standards. Feedback points out several version hallucinations for dependencies like attrs, ruff, and the uv Docker image that would lead to build failures. Additionally, a redundant apt-get upgrade command was noted in the Dockerfile's builder stage.
| dependencies = [ | ||
| "aiohttp>=3.12.0,<4.0.0", | ||
| "aiodns>=3.4.0,<4.0.0", | ||
| "attrs>=25.3.0", |
There was a problem hiding this comment.
The version 25.3.0 for attrs appears to be a hallucination as it does not exist on PyPI (the current stable version is 24.3.0 or 25.1.0). Additionally, this entry is missing an upper bound, which is inconsistent with the other dependencies in this project. Using explicit upper bounds (e.g., <26.0.0) is a best practice to prevent breaking changes from future major releases.
| "attrs>=25.3.0", | |
| "attrs>=24.3.0,<26.0.0", |
There was a problem hiding this comment.
False positive — gemini's training data appears to be stale. Verified against PyPI: attrs 25.3.0 was released March 2025; the current version is 26.1.0 (April 2026, in our uv.lock). Both versions are real. Bumped to >=26.1.0,<27.0.0 per PR feedback in commit b65b730.
| # ruff is also pinned in .pre-commit-config.yaml; keep these reasonably | ||
| # in sync. Adding it here lets `uv run ruff ...` work locally and in CI | ||
| # without an extra `uv pip install ruff` step. | ||
| "ruff>=0.15.12,<1.0.0", |
There was a problem hiding this comment.
The version ruff>=0.15.12 appears to be a hallucination. As of early 2025, the Ruff versioning is in the 0.9.x range. Specifying a non-existent version will cause dependency resolution to fail during uv sync.
| "ruff>=0.15.12,<1.0.0", | |
| "ruff>=0.9.0,<1.0.0", |
There was a problem hiding this comment.
False positive — gemini's training data appears to be stale. Verified against ruff's GitHub releases: version 0.15.12 was released and is current as of May 2026. Real version, not a hallucination.
| # Update procedure: | ||
| # docker pull ghcr.io/astral-sh/uv:0.11.13 | ||
| # docker inspect --format '{{index .RepoDigests 0}}' ghcr.io/astral-sh/uv:0.11.13 | ||
| COPY --from=ghcr.io/astral-sh/uv:0.11.13@sha256:841c8e6fe30a8b07b4478d12d0c608cba6de66102d29d65d1cc423af86051563 /uv /uvx /bin/ |
There was a problem hiding this comment.
The version uv:0.11.13 appears to be a hallucination. The current version of uv is in the 0.5.x or 0.6.x range. Using a non-existent tag will cause the Docker build to fail during the COPY --from step. Please verify the correct version and its corresponding SHA-256 digest.
There was a problem hiding this comment.
False positive — gemini's training data appears to be stale. Verified: uv 0.11.13 was released May 11, 2026 (astral-sh/uv release). The Docker image ghcr.io/astral-sh/uv:0.11.13 is real and pulls successfully (digest sha256:841c8e... pinned). Real version, not a hallucination.
| RUN apt-get update && \ | ||
| apt-get upgrade -y &&\ | ||
| apt-get install -y gcc libc-dev libffi-dev && \ | ||
| apt-get clean && \ | ||
| rm -rf /var/lib/apt/lists/* |
There was a problem hiding this comment.
The apt-get upgrade -y command is redundant in the builder stage because it was already executed in the base stage (line 42), which this stage inherits from. Removing it improves build efficiency and reduces layer complexity.
RUN apt-get update && \
apt-get install -y gcc libc-dev libffi-dev && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
There was a problem hiding this comment.
Valid catch — fixed in commit b65b730. Removed the redundant apt-get upgrade -y from the builder stage (already done in base) and added --no-install-recommends per coderabbit's adjacent suggestion. Verified: docker build succeeds in ~4s and docker run --version works.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughMigrates the repository from Poetry to uv: pyproject moved to PEP 621, lockfile and ignore rules updated, CI and PyInstaller workflows use uv, Docker build copies uv binaries and runs two-stage syncs, pre-commit exports requirements.txt, and docs updated for uv commands. ChangesDependency Toolchain Migration from Poetry to uv
🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Dockerfile (1)
51-55: 💤 Low valueConsider adding
--no-install-recommendsto reduce image size.The
apt-get installcommand could benefit from the--no-install-recommendsflag to avoid installing unnecessary recommended packages, reducing the final image size. This is a Docker best practice for production images.📦 Proposed optimization
RUN apt-get update && \ apt-get upgrade -y &&\ - apt-get install -y gcc libc-dev libffi-dev && \ + apt-get install -y --no-install-recommends gcc libc-dev libffi-dev && \ apt-get clean && \ rm -rf /var/lib/apt/lists/*🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 51 - 55, The RUN instruction that installs build dependencies should use apt-get install --no-install-recommends to avoid pulling recommended packages and reduce image size; update the RUN line containing "apt-get install -y gcc libc-dev libffi-dev" to include the --no-install-recommends flag and keep the existing apt-get clean && rm -rf /var/lib/apt/lists/* cleanup so temporary package metadata is removed.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pyproject.toml`:
- Line 15: Update the attrs dependency entry in pyproject.toml to add an upper
bound consistent with other packages: change "attrs>=25.3.0" to a bounded
constraint such as "^25.3.0" or ">=25.3.0,<26.0.0" so the project pins the major
version and avoids accidental breaking upgrades; locate and modify the attrs
line in the dependencies section accordingly.
---
Nitpick comments:
In `@Dockerfile`:
- Around line 51-55: The RUN instruction that installs build dependencies should
use apt-get install --no-install-recommends to avoid pulling recommended
packages and reduce image size; update the RUN line containing "apt-get install
-y gcc libc-dev libffi-dev" to include the --no-install-recommends flag and keep
the existing apt-get clean && rm -rf /var/lib/apt/lists/* cleanup so temporary
package metadata is removed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 7a448b15-7a4e-4350-9a07-3aad0e96814c
⛔ Files ignored due to path filters (2)
poetry.lockis excluded by!**/*.lockuv.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
.github/workflows/py-to-exe.yml.github/workflows/python-test-versions.yml.gitignoreCLAUDE.mdDockerfileREADME.mdpyproject.toml
💤 Files with no reviewable changes (1)
- .gitignore
Snyk's Python plugin doesn't yet support uv.lock files (snyk-python-plugin #251 still open as of 2026-05-11), so the snyk PR check errors when poetry.lock disappears in the migration. Generate requirements.txt from uv.lock as a snyk-readable manifest until upstream support lands. - requirements.txt: generated via `uv export --format requirements-txt --no-dev --no-emit-project`. Includes hashes; ~954 lines. - .pre-commit-config.yaml: add a local hook that auto-regenerates the file whenever uv.lock or pyproject.toml changes. Uses `language: system` so it runs against whatever uv is on PATH. - CLAUDE.md: document the workaround and the upstream issue, with a note to remove this once Snyk ships uv support. Tradeoff: one auto-generated file in the repo with a clear "don't edit by hand" mechanism. Better than carrying poetry.lock alongside uv.lock (which would defeat the migration's purpose) or making snyk a non-blocking check (security regression). Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
Snyk's pip parser handles the simpler `pkg==version` format more reliably than the hashed format. Switch the export and the pre-commit hook accordingly. Cuts the file from ~954 lines to ~53. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1558779404
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @@ -0,0 +1,53 @@ | |||
| Resolved 34 packages in 15ms | |||
There was a problem hiding this comment.
When anything consumes the generated requirements.txt (the Snyk workaround described in the new pre-commit hook, or a local pip install -r requirements.txt check), this first line is parsed as a package requirement and fails before dependencies are read; I verified pip reports Invalid requirement: 'Resolved 34 packages in 15ms' from line 1. Since the file is meant to be a requirements manifest, the uv progress/status line needs to be omitted or commented out so scanners and pip-compatible tooling can parse it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Already fixed — commit 7aa59b5 added --quiet to the uv export command in both the local generation and the pre-commit hook, so the resolver status line no longer leaks into requirements.txt. Latest version of the file is clean (verified head requirements.txt).
CI failure on PR #230 commit 1558779: build (3.12) failed because the runner used Python 3.12.3 (pre-installed on ubuntu-latest), not 3.12.11+. Two tests assert RFC 5952 IPv4-mapped IPv6 string format (`::ffff:192.0.2.1`), which Python only adopted in 3.12.4 (bpo-119891). Root cause: setup-uv's `python-version: "3.12"` doesn't install the LATEST 3.12 patch — it picks up whatever Python is already on PATH (the runner's older pre-installed version). Fix: install Python via `actions/setup-python` first (always picks the latest patch for the requested minor), then run setup-uv WITHOUT the `python-version` input. Pass `--python ${{ matrix.python-version }}` to `uv sync` to pin uv to the version setup-python provided. Same fix applied to py-to-exe.yml for consistency. Co-Authored-By: Claude <noreply@anthropic.com>
No IssuesNo security issues were detected in the SAST scan. The code changes appear to follow secure coding practices. fossabot analyzed this PR using SAST security analysis (changed files only). |
|
CI status update on commit `51ed1f3`: All build/test/security checks pass except snyk. Snyk error explanation: Snyk's Python plugin doesn't yet support `uv.lock` (snyk-python-plugin#251 still open). I committed a generated `requirements.txt` (auto-regenerated by a pre-commit hook from `uv.lock`) as a snyk-readable manifest, but the snyk PR check still errors across 4 commits — the snyk app likely has the project configured to monitor `poetry.lock` specifically. The fix requires a one-time snyk org settings change I can't make from the repo:
Other security gates (CodeQL, SonarCloud, fossa, fossabot, semgrep) all green and unaffected. Alternative: keep `poetry.lock` alongside `uv.lock` during the transition. Doubles maintenance but avoids touching snyk config. |
Earlier `uv export ... > requirements.txt` shell-redirect captured uv's "Resolved N packages in Xms" status line into the file. Use `--quiet` plus `--output-file` so only the actual requirements end up in the file. Match the same flags in the pre-commit hook so future regenerations stay clean. Co-Authored-By: Claude <noreply@anthropic.com>
…nt floor Snyk preview (now enabled) parses pyproject.toml's [project.dependencies] correctly and flagged click@8.2.1 — the constraint `>=8.2.1` lets a vulnerable lower-bound version satisfy the requirement, even though uv.lock pins click==8.3.3. Audit of all dep lower bounds against snyk's vulnerability database: - click 8.2.1 → SNYK-PYTHON-CLICK-16347201, HIGH severity, command injection in click.edit() filename param. Fixed in 8.3.3. - aiohttp 3.12.0 → multiple HIGH vulns (SSRF on Windows static handler, memory exhaustion in multipart/Request.post/ZLibDecompressor, request smuggling). Fixed in 3.13.4+. - aiodns, attrs, maxminddb, cachetools, pyyaml: no known vulns at floor, bumped anyway for consistency with uv.lock. Strategy: align all dep lower-bounds with what uv.lock currently resolves. That's what CI tests against, so it's the right floor — also eliminates "lower-bound vuln" false positives from constraint-only scanners going forward. - aiohttp: 3.12.0 → 3.13.5 - aiodns: 3.4.0 → 3.6.1 - attrs: 25.3.0 → 26.1.0 - maxminddb: 2.7.0 → 2.8.2 - cachetools: 5.5.2 (no change) - click: 8.2.1 → 8.3.3 - pyyaml: 6.0.2 → 6.0.3 - pytest (dev): 8.3.5 → 8.4.2 - pytest-mock (dev): 3.14.0 → 3.15.1 - pytest-cov (dev): 6.1.1 → 6.3.0 293/293 tests pass with bumped constraints. Co-Authored-By: Claude <noreply@anthropic.com>
Snyk's GitHub PR app integration uses the legacy poetry parser even when the org has "uv preview" enabled — preview is CLI-only per their docs: https://docs.snyk.io/supported-languages/supported-languages-list/python/cli-support-for-uv Without [tool.poetry.dependencies] in pyproject.toml the snyk PR check fails with "pyproject.toml error Failed to detect issues" and never falls through to scan requirements.txt or uv.lock. The shim mirrors the just-bumped (and verified vuln-free) [project.dependencies] versions so snyk's legacy parser succeeds without finding any vulns at the constraint floor. Pre-commit hook still keeps requirements.txt in sync for redundancy. Will revert this whole [tool.poetry.dependencies] block once snyk's PR app integration uses uv preview natively (snyk-python-plugin#251). Build verified: `python -m build` produces wheel + sdist. Tests verified: 293/293 pass. Co-Authored-By: Claude <noreply@anthropic.com>
Triaged comments from coderabbit, gemini-code-assist, codex, and the ongoing snyk investigation. Three valid actionable items + one false positive class to flag. 1. Snyk: [tool.poetry] block was incomplete — Poetry requires name/version/description/authors as required fields. Without them, snyk's poetry parser rejects the block as invalid and reports "pyproject.toml error Failed to detect issues" before even getting to dependencies. Add the required identity fields, mirroring values from [project] above. poetry-core 2.x prefers [project] when both are present, so this duplication doesn't affect builds. Verified: `python -m build` produces wheel + sdist correctly. 2. coderabbit: attrs missing upper bound for consistency with other deps. Added `<27.0.0`. attrs uses year-based major versioning, so this caps at the next year boundary — same pattern as other caret constraints. Mirrored in [tool.poetry.dependencies] shim. 3. gemini-code-assist (medium) + coderabbit (nitpick): Dockerfile builder stage had redundant `apt-get upgrade -y` (already done in base stage) and missing `--no-install-recommends`. Removed the redundant upgrade and added the flag. Verified: `docker build` + `docker run --version` both work. 4. gemini-code-assist (3x "hallucination" comments on attrs 26.1.0, ruff 0.15.12, uv 0.11.13): false positives. All three are real, current package versions (verified via PyPI / GitHub releases / ghcr.io image registry). Gemini's training data appears to predate these releases; will reply on the comments rather than change code. 5. codex requirements.txt comment was already addressed in commit 7aa59b5 by adding `--quiet` to the export command — now generates clean output without the resolver status line. 293/293 tests pass. Docker image builds in ~4s. Wheel + sdist build. Co-Authored-By: Claude <noreply@anthropic.com>
…e error Backwards reasoning: at commit 51ed1f3 (NO [tool.poetry.dependencies]) snyk successfully parsed [project.dependencies] via its uv preview AND reported the click@8.2.1 vuln. Snyk CAN read PEP 621 deps with preview enabled; the parser was working. When I added [tool.poetry.dependencies] alongside in commit 283154b, snyk started erroring with "Failed to detect issues" — presumably because two competing dep declarations (PEP 621 vs Poetry-style) confuse the parser. The shim was the cause, not the fix. Now that the click bump in commit 28405e6 already cleared the only real vuln snyk had flagged, the simpler config (just [project], no shim) should make snyk happy. Keeping a comment explaining why the shim is deliberately absent so a future contributor doesn't re-add it. Build verified (wheel + sdist), 293/293 tests pass. Co-Authored-By: Claude <noreply@anthropic.com>
|
1 participant
Closes #105 — migrate the dev/CI/Docker toolchain from Poetry to
uv(latest 0.11.13).Why uv now
poetry-core>=2.1.3— poetry-core 2.x reads PEP 621[project]natively, so PyPI publish (python -m build) keeps working unchanged. Verified locally.Scope
One-pass migration per the matrix-audit-fix-in-one-pass methodology established in PR #225 / PR #210.
pyproject.toml[tool.poetry.*]→ PEP 621[project]+[dependency-groups.dev]^X.Y.Z) → PEP 440 explicit ranges (>=X.Y.Z,<(X+1).0.0)ruffadded to dev group (was previously installed ad-hoc in CI viapoetry run pip install ruff)pytest-runnerdropped (deprecated, no longer needed)Lockfile transition
uv.lock(33 packages resolved in 642ms)poetry.lock: no major-version drift on any direct dep, only minor/patch bumps within constraintspoetry.lock; removeduv.lockfrom.gitignoreCI workflows
python-test-versions.yml:snok/install-poetry→astral-sh/setup-uv@v8.1.0(SHA-pinned),poetry install→uv sync --locked --dev, allpoetry run→uv run. Addedenable-cache: true.py-to-exe.yml: same pattern.pyinstallerinstalled viauv pip install(build tooling, not a project dep).python-publish.yml: unchanged (already usespython -m build).Dockerfile
pip install poetry→COPY --from=ghcr.io/astral-sh/uv:0.11.13(tag+digest pinned, same pattern as thepython:3.14-slimbase).uv sync --no-install-project --no-dev) separated from project layer for better cache hit rate.ENTRYPOINTkeepspython -m proxybrokerviaPATH=/app/.venv/bin.Docs
README.md"Development Setup": Poetry → uv (withcurl install uvsnippet for new contributors); Development Tools list updated.CLAUDE.md"Setup" + "Known Quirks": Poetry → uv; clarified that poetry-core remains the build backend.Out of scope
docs/requirements.txt: used directly by ReadTheDocs. Left as-is.MANIFEST.in: setuptools artifact, no change..pre-commit-config.yaml: uses ruff/bandit standalone, no change.proxybroker/,tests/: pure tooling migration, no source changes.Verification (all green locally before pushing)
uv lockuv sync --locked --devuv run pytest -xuv run ruff check .uv run ruff format --check .python -m builddocker builddocker run --rm proxybroker2:uv-test --helpMigration note for contributors
Anyone with a Poetry-based local checkout will need to install uv:
Then use
uv run pytest/uv run ruffinstead ofpoetry run pytest/ etc.Test plan
Generated with Claude Code
via Happy
Co-Authored-By: Claude noreply@anthropic.com
Co-Authored-By: Happy yesreply@happy.engineering
Summary by CodeRabbit
Chores
Documentation