build(deps): update numpy requirement from >=2.5.2 to >=2.5.3 in /services/data - #516
dependabot[bot] wants to merge 1 commit into
Conversation
Updates the requirements on [numpy](https://github.com/numpy/numpy) to permit the latest version. - [Release notes](https://github.com/numpy/numpy/releases) - [Changelog](https://github.com/numpy/numpy/blob/main/doc/RELEASE_WALKTHROUGH.rst) - [Commits](numpy/numpy@v2.5.2...v2.5.3) --- updated-dependencies: - dependency-name: numpy dependency-version: 2.5.3 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
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. |
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
The previous commit's changelog entry blamed this environment's package index for resolving differently from the prod container -- "whatever this environment's egress serves as an index is not what the prod container sees". That was a guess dressed as a diagnosis, and it was wrong. pip-compile treats an EXISTING output file as constraints: it moves only what the inputs force and leaves every other pin alone. The local runs wrote to fresh scratch paths, so there were no pins to preserve and the whole graph resolved to latest -- hence "34 packages move". Compiling into a copy of the REAL lock instead moves ZERO packages, measured just now: numpy stays 2.5.2, manifold3d 3.5.2, alembic 1.20.0. That is also why only alembic moved in CI; its floor was the only one that changed. What broke the wrong story was checking a fact rather than reasoning from the gap: numpy 2.5.3 and manifold3d 3.5.3 both exist on PyPI with cp312 manylinux wheels, so "the index is different" had nothing left to stand on, and the remaining candidate was the one variable the two runs did not share -- the output path. TWO THINGS FOLLOW, and the second is the one that will save time later. The reproduction rule is concrete: compile IN PLACE, to the lock you intend to replace. A regeneration aimed at a new path is a different operation and answers a different question. Nothing was wrong with the local toolchain, and the earlier entry would have taught the next reader to distrust it. And it settles the remaining sweep. #517 (manifold3d >=3.5.3) and #516 (numpy >=2.5.3) fail the API test gate because they raise floors only in services/data/requirements.txt, which pip-compile never reads -- requirements.in says so in a comment. Raising the floor in BOTH files will move those pins, for exactly the reason alembic's did: a floor that changes is a constraint the existing pin no longer satisfies. That is now a measured mechanism rather than a hope. I wrote an entry criticising confident measurement over checks that can fail, and put a confidently wrong cause inside it. Correcting the record in place rather than quietly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA
…517) Dependabot raised these floors only in services/data/requirements.txt, and both PRs fail the API test gate for a reason the tree already documents. services/api/ requirements.in carries the explanation on the numpy line itself: "floor raised WITH services/data/requirements.txt: pip-compile reads only this file, so a floor raised only there cannot move the lock." So the failure is structural rather than incidental. test_lock_satisfies_requirements reads BOTH requirements files and checks them against requirements.lock -- deliberately, because the API image RUNS the data service's code while installing only the API's lock, and a floor raised in the data requirements is otherwise a claim nothing enforces. With the lock still pinning numpy==2.5.2 and manifold3d==3.5.2, a floor of 2.5.3/3.5.3 is unsatisfied and the gate fails. Neither PR could ever have gone green alone. Both floors move here, so pip-compile sees a constraint the existing pins no longer satisfy, and the lock follows. MEASURED, NOT ASSUMED: compiling with both floors raised moves EXACTLY TWO pins -- manifold3d 3.5.2 -> 3.5.3 and numpy 2.5.2 -> 2.5.3 -- and nothing else. Both versions exist on PyPI with cp312 manylinux wheels, checked directly rather than inferred. This commit deliberately leaves the lock stale, as the alembic bump did: the recompile belongs in python:3.12-slim, which lockfile.yml provides, and pushing this fires it on the requirements.in path. Its Verify step is red on this commit alone and prints the diff the next commit transcribes. That is the documented bootstrap path, not a failure to chase. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA
…orrection said to Exactly two pins move: numpy 2.5.2 -> 2.5.3 and manifold3d 3.5.2 -> 3.5.3. Zero packages added, zero removed, nothing else touched -- which is what was predicted before the floors were raised, from a measurement rather than a hope. THIS USED THE LOCAL COMPILER, and that is a deliberate reversal of how the alembic lock in the previous PR was produced. There the lock bytes were transcribed out of CI's Verify diff, because a local resolve had produced a wildly different answer and could not be trusted. The cause turned out to be the invocation: pip-compile treats an EXISTING output file as constraints and moves only what the inputs force, while those runs wrote to fresh scratch paths where nothing was preserved. Compiled in place, against the real lock, the local tool is the same tool CI runs. The runtime says the same thing more loudly than the diff does. The fresh-path compile took over forty minutes, because it re-resolved and re-hashed the entire graph; this one took THIRTY-NINE SECONDS, because an in-place compile only has to fetch what actually changed. A forty-minute run and a forty-second run were never doing the same work, and that was visible from the start for anyone who thought to look at the clock. Transcribing from CI was also not available here even if wanted: alembic had two hashes and fit in the Verify step's `head -60`, while manifold3d alone carries dozens of wheel hashes, so the printed diff is truncated well before the content ends. The artifact that holds the full file sits on a host this environment's egress policy blocks. So the choice was a correctly-invoked local compile or nothing -- and CI's Verify step will confirm byte-identity either way, which is the property that makes either route safe. Verified: test_lock_satisfies_requirements (the gate that reads BOTH requirements files and is the reason #516 and #517 could never pass alone), test_declared_imports and test_desktop_paths all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA
…#547) Supersedes dependabot's #516 (numpy) and #517 (manifold3d), neither of which could have gone green as filed. WHY THEY WERE STUCK, and it is written in the file they were editing. Dependabot raises these floors in services/data/requirements.txt only. pip-compile never reads that file -- services/api/requirements.in says exactly this in a comment on the numpy line: "floor raised WITH services/data/requirements.txt: pip-compile reads only this file, so a floor raised only there cannot move the lock." Meanwhile test_lock_satisfies_requirements reads BOTH requirements files and checks them against requirements.lock, deliberately, because the API image RUNS the data service's code while installing only the API's lock. So a floor above the lock's pin fails that gate by construction. Structural, not incidental: no rebase or recreate could ever have fixed either PR. Raising both floors gives pip-compile a constraint the existing pins no longer satisfy, and the lock follows. Exactly two pins move -- numpy 2.5.2 -> 2.5.3 and manifold3d 3.5.2 -> 3.5.3 -- with zero added and zero removed. Predicted from a measurement before the change was made, then confirmed by lockfile.yml's Verify step on the committed bytes. ON WHERE THE LOCK CAME FROM, because it reverses what the previous PR concluded. #546 transcribed its lock out of CI's Verify diff, because a local resolve had produced an unrecognisable answer. This one was compiled locally, and that is correct now for a reason #546 established: pip-compile treats an EXISTING output file as constraints and moves only what the inputs force, while a fresh output path preserves nothing and re-resolves the world. Compiled in place against the real lock, the local tool is the tool CI runs -- and Verify agreed byte-for-byte on a lock carrying hundreds of hash lines rather than alembic's two. The clock said it before the diff did: the fresh-path compile took over forty minutes, the in-place compile took thirty-nine seconds. Two runs of the same command differing sixty-fold in cost were never doing the same work, and that was visible from the start without reading a single package name. Transcription was not available here in any case. Verify prints head -60 of its diff, which alembic's two hashes fit inside and manifold3d's dozens of wheel hashes do not, and the artifact holding the full file sits behind an egress block in this environment. Both routes end at the same gate, which is what makes either one safe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA
|
Superseded by #547, merged as Why this PR could never have gone green, however many times it was rebased or recreated. It raises the floor in Meanwhile So the failure was structural. The floor had to move in both files at once, which is not a shape dependabot can produce. What #547 did: raised Both target versions were confirmed to exist on PyPI with cp312 manylinux wheels before the floors were raised, rather than assumed from the version number. Generated by Claude Code |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
1 participant
Updates the requirements on numpy to permit the latest version.
Release notes
Sourced from numpy's releases.
... (truncated)
Changelog
Sourced from numpy's changelog.
... (truncated)
Commits
dd88c0cMerge pull request #32511 from charris/prepare-2.5.3edcac6aREL: Prepare for the NumPy 2.5.3 releasefd4d908Merge pull request #32509 from charris/backport-3249665bb1daBUG: fix crash in ufunc.resolve_dtypes with a Python scalar type (#32496)294956eMerge pull request #32506 from charris/backport-3250326428d9DOC: fix scipy docs links in intersphinx mapping (#32507)5fab1cbDOC: use static scipy doc site for intershpinx (#32503)7beed2fMerge pull request #32481 from ngoldbaum/stringdtype-backport8972f70Merge pull request #32478 from charris/backport-32466ab1b589Merge pull request #32477 from charris/backport-32423Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)