Conversation
There was a problem hiding this comment.
🟢 Approval recommended
No unresolved blocking issues were identified.
Pull request overview
Raises dependency minimums to NumPy 2-compatible releases and refreshes the lockfile.
Changes:
- Updates six dependency lower bounds.
- Regenerates Python/platform-specific resolutions in
uv.lock.
File summaries
| File | Summary |
|---|---|
pyproject.toml |
Raises direct dependency lower bounds. |
uv.lock |
Records updated dependency resolutions and markers. |
Review details
- Files reviewed: 1/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
2ac2947 to
bc6d9b7
Compare
82e4fd2 to
021a5f6
Compare
Add the missing comma between the `matplotlib` and `numpy-1` matrix entries in `.github/workflows/intelligent-testing.yml` so the GitHub Actions matrix parses correctly.
Broaden the intelligent-testing workflow to include strict dependency-resolution checks for Python 3.10 and 3.12, plus NumPy 1/2 and Matplotlib upgrade variants. This improves compatibility coverage and validates resolver behavior beyond the previous narrower matrix.
Restore exclusion of matplotlib 3.7 and 3.7.1 from the base dependencies, and drop the redundant numpy cap from the `tf-cu12` extra because TensorFlow 2.18 already declares the required numpy range.
Add a `strict_cells` workflow input and use it to make only `matrix.strict` canary lanes fail the job outright. The intelligent testing workflow now enables strict cells for pushes and same-repo PRs while keeping fork PRs non-blocking, and the reporting step skips annotations for lanes that already fail normally.
This reverts commit e5255f0.
bc6d9b7 to
a12c9c6
Compare
835a08c to
c2fd015
Compare
deruyter92
left a comment
There was a problem hiding this comment.
As a product decision (force a more modern stack) I see a good value of this PR.
But to me this sounds entirely separate from the discussion on numpy in the associated PRs. The goal in those PRs is to support numpy 2.0 for broad compatibility, not to make sure that users don't end up with numpy 1.x.
To me the benefits from enforcing a modern stack right now do not feel like they outweigh the restrictive downsides: if our users work with old other scientific software, it might be helpful to keep the lower-bounds low for flexibility, unless we really can't support.
maybe we should add a test lane first with pip resolution=lowest-direct to test if our codebase contains unsupported usage. In that case we need to update the lower-bounds. If not necessary, I wouldn't maybe for now.
@C-Achard do you agree?
|
@deruyter92 Yes totally! Sorry if it sounds like it's tightly coupled to the other PRs, it isn't. |
ddace9a to
d476967
Compare
Motivation
#3499 removes the
numpy<2upper bound, but several dependencies still have a np1-only lower bound.matplotlib>=3.3,!=3.7,!=3.7.1>=3.9pycocotools>=2.0.8scikit-image>=0.17>=0.24scipy>=1.9>=1.13statsmodels>=0.11>=0.14.2tables>3.8>=3.10.1Re:
tablestables3.10.0 still declaresnumpy<2,>=1.20.0; the cap lifts in 3.10.1. It cannot go higher either as 3.10.2+ requires Python ≥3.11.Not changed here
numba>=0.60andopencv-python-headless>=4.10.0.84are in Follow-up fixes for numpy2 compatibility #3508Note: If we want to narrow this as much as possible, we could limit to tables and scipy as they are the ones with numpy upper bounds.