chore(deps): stop dependabot relaxing the scipy runtime pin - #2822
Merged
Merged
Conversation
PR #2804 proposed moving the scipy ceiling from 1.15 to 1.19, relaxing a pin whose rationale sits directly above it and was written three days earlier. Closing that PR fixes it once; this stops it recurring every Friday. Why the pin cannot be expressed as a dependency constraint: package metadata does not describe the failure. scipy 1.15 declares numpy>=1.23.5 and numpy<2.5, so pip resolves it cleanly against the base image's numpy 1.26 and run_ui.py then dies at IMPORT on ufuncs (sph_legendre_p) that only register under numpy 2.x. A green resolve and a broken container. scipy 1.18 is a different failure mode -- it requires numpy>=2.0.0 outright. So the proposed ceiling admits two distinct breakages, and only a manual pin plus an explicit ignore rule can prevent them. Verified against PyPI rather than taken from the comment: scipy 1.14.1 requires_python>=3.10 numpy>=1.23.5,<2.3 resolves + runs scipy 1.15.0 requires_python>=3.10 numpy>=1.23.5,<2.5 resolves, dies at import scipy 1.18.0 requires_python>=3.12 numpy>=2.0.0 hard conflict .github/dependabot.yml had ZERO ignore blocks before this, so nothing prevented the bump from returning. Adds the reciprocal pointer in requirements.txt so an editor who relaxes one finds the other. Validated: dependabot.yml parses, 6 update blocks preserved, the ignore rule reads back as {dependency-name: scipy, versions: ['>=1.15']}, and the pin itself is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jxd5gryAFPXwhjaCMw9Qrx
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 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 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
github-actions
Bot
added
chit-aware
Contributor
🔏 CHIT-aware change — control-body routingThis PR touches a CHIT-aware service (ports 8086/8087/8103/8106/8113/9224 surface). Before a Control-Body ACK:
Advisory routing only — the blocking contract check is CHIT Contract. |
![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: e6ec169f33
ℹ️ 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".
Codex P2, and it found a real inconsistency — though not one that can be resolved by inference, so the pin stays and the contradiction is now recorded where the next editor will hit it. The rationale says the image runs numpy 1.26, and concludes scipy >=1.15 would break at import. But `requirements.lock` resolves `numpy==2.2.6` alongside `scipy==1.14.1`, and it was introduced by the SAME commit that added the scipy pin (#2750, 59cc5e8, "pin scipy<1.15 against the numpy 1.26 base image"). The Dockerfile has installed with `--constraint requirements.lock` since 2026-05-19, well before that. So the fix for "the base image has numpy 1.26" shipped a lock that pins numpy to 2.x. If that constraint lands, scipy 1.15-1.18 are all compatible — 1.18 needs numpy>=2.0.0, which 2.2.6 satisfies — and `>=1.15` blocks valid updates forever. Not relaxed, because the opposite is also possible and the difference is not decidable from the tree: constraints apply to what is INSTALLED, and numpy 1.26 already satisfies scipy 1.14.1 (numpy>=1.23.5,<2.3), so a resolver may leave it alone and never apply the constraint. Relaxing a runtime pin on a guess buys a container that boots and then dies at import with the exact error the pin exists to prevent. The comment now carries the one command that settles it against the built image, and the branch to take for either answer. Verify, then act — do not delete this note and relax the pin in one step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f
…about it
Codex was right, and the earlier reply on this PR was right to refuse to
relax the pin on inference. Docker became available, so it stopped being
inference.
MEASURED against the built image, /opt/venv-a0:
numpy 2.3.5
scipy 1.16.3
import scipy.special -> OK
sph_legendre_p present -> True
scipy.stats, scipy.linalg -> OK
That is scipy >=1.15 running on numpy 2.x, with the exact ufunc the rationale
names present and importable. The incompatibility is real but CONDITIONAL on
numpy 1.26, and nothing in this build path produces 1.26: requirements.lock
pins numpy==2.2.6 and the measured image carries 2.3.5.
Stated because it limits the claim: that image was built 2026-08-23, two days
BEFORE the pin landed (59cc5e8, 08-25), so it does not test the pin itself.
It tests the COMPATIBILITY CLAIM, which is what the ignore rests on. I nearly
published the stronger conclusion before checking the image date; the date is
what kept it honest.
Bound moved to where the constraint actually is: scipy 1.19 requires
numpy>=2.5, which neither 2.2.6 nor 2.3.5 satisfies. 1.15 through 1.18 are
fine on numpy 2.x -- including 1.18, which needs numpy>=2.0.0 and therefore
was never the "hard conflict" the old comment claimed. Ignoring >=1.15 blocked
four minor lines for a break that only happens on a numpy this image does not
have.
versions: [">=1.15"] -> [">=1.19"]
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 30, 2026
…lisions main moved while #2818 sat blocked: #2813, #2822, #2825, #2826, #2827, #2830, #2831, #2832, #2837, #2838 all landed, plus the CodeQL alert cleanup on main. Automatic merge, no conflicts. Re-ran the checks that matter for a merge of this size rather than assuming a clean `git merge` means a correct one: duplicate top-level definitions 4 modules, all 4 already shadowed on main. mcp_server.py stays clean, so the collision fixed earlier held and nothing new joined it. hardening_ratchet debt=6, no new, no stale validate-dockerfile-paths OK (93 dockerfiles, 83 referenced) validate-command-anchors 498 baselined, 0 new, no stale Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X9mpK1ZFjexjthZbvcb94f
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the loop on #2804, which proposed relaxing the scipy ceiling past a pin whose rationale sits directly above it — written three days before the bump.
Closing that PR fixes it once. This stops it recurring every Friday.
Why the pin can't be a dependency constraint
Package metadata does not describe the failure:
requires_python1.14.1(ceiling)>=3.10numpy>=1.23.5,<2.31.15.0>=3.10numpy>=1.23.5,<2.51.18.0>=3.12numpy>=2.0.0The middle row is why a manual pin exists. scipy 1.15's declared metadata permits numpy 1.26, so pip resolves it without complaint and
run_ui.pythen dies on ufuncs (sph_legendre_p) that only register under numpy 2.x. Green resolve, broken container.So the proposed ceiling admits two distinct breakages — a silent one (1.15–1.17) and a hard one (1.18).
Queried live from PyPI rather than taken from the comment.
What changed
ignorerule in the agent-zero pip ecosystem..github/dependabot.ymlhad zero ignore blocks before this, so nothing prevented the bump from returning.requirements.txt, so an editor who relaxes one finds the other. They were previously independent and could drift silently.Validated
dependabot.ymlparses; all 6 update blocks preserved; the rule reads back as{dependency-name: scipy, versions: ['>=1.15']}; the pin itself is byte-unchanged (comment-only addition there).🤖 Generated with Claude Code
https://claude.ai/code/session_01Jxd5gryAFPXwhjaCMw9Qrx