chore(deps): five python floors + the lock recompiled in the prod image (#356 #357 #359 #365 #366) - #368
Conversation
reportlab >=5.0.1 (#356 #359), scipy >=1.18.1 (#357), pyhanko >=0.36.2 (#365), sentry-sdk >=2.68.1 (#366). Mirrored into services/data/requirements.txt where it declares the same package, because requirements.in carries those floors too and the two are maintained together. anthropic (#362, >=0.120.0 -> >=1.0.0) is DELIBERATELY NOT HERE. It is a major on the LLM SDK and wants its own change with the call sites actually read. The lock is compiled in python:3.12-slim by .github/workflows/lockfile.yml — it cannot be regenerated correctly on Windows (uvloop has no Windows build, colorama is absent from a Linux-compiled lock), so this push exists to make that workflow produce the artifact.
Produced by .github/workflows/lockfile.yml on the previous commit of this branch — the workflow
uploads the freshly-compiled lock as an artifact even when its verify step fails, which is the
documented bootstrap path and the only correct one here: the lock carries --generate-hashes and is
resolved in the prod image, so a Windows compile would produce a different artifact (uvloop has no
Windows build; colorama is absent from a Linux-compiled lock).
EXACTLY FIVE PINS MOVED, 110 in and 110 out — no package added or removed:
pyhanko 0.35.2 -> 0.36.2
pyhanko-certvalidator 0.31.1 -> 0.31.4 (transitive, pulled by pyhanko)
reportlab 5.0.0 -> 5.0.1
scipy 1.18.0 -> 1.18.1
sentry-sdk[fastapi] 2.66.1 -> 2.68.1
anthropic stayed at 0.120.2, which is the point of holding #362 out of this batch.
Verified by parsing both locks and diffing the PIN SETS rather than by reading a textual diff. My
first two attempts under-reported: one regex did not allow bracketed extras, so it matched no
"sentry-sdk[fastapi]==" line at all and reported sentry as unmoved when it had in fact moved. A diff
is only as good as the pattern that feeds it, and a pattern that silently matches nothing looks
exactly like agreement.
pyhanko 0.35.2 -> 0.36.2 is the one worth watching here: it is the PDF-signing stack, and this venv
cannot install the lock to exercise it (Windows), so CI is the authority for that bump.
|
Strix is installed on this repository, but we couldn't run this PR security review because this workspace's trial has ended. Add a card to resume code reviews here. So far, Strix has reviewed 28 pull requests, surfaced 3 security issues (1 critical/high) and blocked 2 risky merges across this workspace. |
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe pull request raises minimum versions for SciPy and ReportLab in both services, and for pyHanko and Sentry SDK in the API service. No dependencies are added or removed. ChangesDependency version floors
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This change raises supported Python dependency floors and refreshes the API lockfile without introducing an identified product or production risk; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Description checkExplanation The description explains the dependency changes, batching rationale, CI lockfile process, intentional exclusion, and linked issues. It omits the repository checklist, but the main required context is complete. Full details: Out of Scope Changes checkExplanation The linked issue covers only the ReportLab update in services/data. The pull request also changes SciPy, pyhanko, pyhanko-certvalidator, sentry-sdk, and the API ReportLab floor. These changes are not supported by the single provided linked issue. Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)
✨ 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 |
1 participant
Batches the five Python floor bumps that share one artifact —
services/api/requirements.lock—and commits the lock compiled by
.github/workflows/lockfile.ymlinpython:3.12-slim.Why batched
Each of these raises a floor above what the lock pins, and
test_lock_satisfies_requirementschecks exactly that, so merging any one alone reddens main. They also all resolve through the same
lock, so merging singly would recompile it four times.
110 pins in, 110 out — nothing added or removed.
Why the lock came from CI rather than from here
It carries
--generate-hashesand is resolved in the prod image. A Windows compile produces adifferent artifact:
uvloophas no Windows build, andcoloramais absent from a Linux-compiledlock. The workflow uploads the freshly-compiled lock as an artifact even when its verify step fails,
which is the documented bootstrap path. The follow-up push then made that same workflow pass its
"verify committed lock is up to date" step — that success is the evidence the lock matches a
fresh compile.
Held back deliberately
anthropic >=0.120.0 → >=1.0.0(#362) is NOT in this batch. It is a major on the LLM SDK andwants its own change with the call sites read. Including it would put a breaking-change candidate
inside a routine floor bump, and would block four safe bumps behind one risky resolution. The lock
here keeps
anthropic==0.120.2.What needs CI, not local verification
pyhanko 0.35.2 → 0.36.2is the PDF-signing stack. This machine's venv cannot install the lock atall (the Windows problem above), so CI is the authority for that bump — which is the whole
reason this is a PR rather than a direct push.
Closes #356, #357, #359, #365, #366
Summary by CodeRabbit