CI typecheck fails: numpy 2.5.0 stubs use PEP 695 type statements, incompatible with mypy python_version = "3.10"
Summary
make check_code_quality (the mypy roboflow step in CI) started failing on fresh installs after numpy 2.5.0 was released on 2026-06-21. numpy 2.5.0 dropped Python 3.11 support specifically so its bundled type stubs could move to PEP 695 type statement syntax (Python 3.12+). This repo's mypy config targets Python 3.10, so mypy cannot parse the new stubs and errors out — regardless of the mypy version or the Python interpreter running CI.
This is a numpy × mypy version interaction, not a bug in roboflow code. The repo has no upper bound on numpy in its dev/test extra, so pip install ".[dev]" now resolves numpy 2.5.0 and breaks the typecheck gate on every push and PR.
Reproduce
python3 -m venv env && source env/bin/activate
pip install -e ".[dev]" # pulls numpy 2.5.0
make check_code_quality # ruff passes, mypy fails
CI matrix affected: all of ubuntu-latest / windows-latest × 3.10 / 3.11 / 3.12 / 3.13, since the mypy target (not the interpreter) is pinned to 3.10.
Root cause
pyproject.toml:
[tool.mypy]
python_version = "3.10"
requirements.txt:
setup.py lists numpy in the dev extra with no upper bound.
numpy 2.5.0 release notes confirm the move to PEP 695 stubs (and that dropping Python 3.11 was the enabling step): https://numpy.org/devdocs/release/2.5.0-notes.html
An independent project hit the same break on 2026-06-22 and fixed it by capping numpy<2.5 in their dev extra: bertravacca/ev-flow@3abab0d — their note confirms mypy 2.0 and 2.1 both fail under a py3.10 target, so this is not a mypy-version issue.
Suggested fix
Cap numpy<2.5 in the dev/test extra only (setup.py), leaving the runtime requirements.txt constraint (numpy>=1.18.5) untouched so end users are not affected:
# setup.py — dev extra
"numpy<2.5",
This mirrors the approach taken by ev-flow and keeps the runtime dependency policy unchanged.
A longer-term alternative is to bump [tool.mypy] python_version to "3.12" once the repo drops Python 3.10/3.11 support, at which point the cap can be removed.
Impact
- Blocks all incoming PRs from passing CI (the
🧹 Check code quality step in .github/workflows/test.yml).
- Blocks merges to
main for any contributor whose branch doesn't already have a pinned numpy in a local venv.
- No runtime impact — the SDK itself works fine on numpy 2.5.0; only the typecheck gate is broken.
Environment
- numpy: 2.5.0 (released 2026-06-21)
- mypy: any version (confirmed 2.0 and 2.1 both fail under
python_version = "3.10")
- Repo:
roboflow/roboflow-python, current main
CI typecheck fails: numpy 2.5.0 stubs use PEP 695
typestatements, incompatible withmypy python_version = "3.10"Summary
make check_code_quality(themypy roboflowstep in CI) started failing on fresh installs after numpy 2.5.0 was released on 2026-06-21. numpy 2.5.0 dropped Python 3.11 support specifically so its bundled type stubs could move to PEP 695typestatement syntax (Python 3.12+). This repo's mypy config targets Python 3.10, so mypy cannot parse the new stubs and errors out — regardless of the mypy version or the Python interpreter running CI.This is a numpy × mypy version interaction, not a bug in roboflow code. The repo has no upper bound on numpy in its dev/test extra, so
pip install ".[dev]"now resolves numpy 2.5.0 and breaks the typecheck gate on every push and PR.Reproduce
CI matrix affected: all of
ubuntu-latest/windows-latest×3.10/3.11/3.12/3.13, since the mypy target (not the interpreter) is pinned to 3.10.Root cause
pyproject.toml:requirements.txt:setup.pylistsnumpyin the dev extra with no upper bound.numpy 2.5.0 release notes confirm the move to PEP 695 stubs (and that dropping Python 3.11 was the enabling step): https://numpy.org/devdocs/release/2.5.0-notes.html
An independent project hit the same break on 2026-06-22 and fixed it by capping
numpy<2.5in their dev extra: bertravacca/ev-flow@3abab0d — their note confirms mypy 2.0 and 2.1 both fail under a py3.10 target, so this is not a mypy-version issue.Suggested fix
Cap
numpy<2.5in the dev/test extra only (setup.py), leaving the runtimerequirements.txtconstraint (numpy>=1.18.5) untouched so end users are not affected:This mirrors the approach taken by ev-flow and keeps the runtime dependency policy unchanged.
A longer-term alternative is to bump
[tool.mypy] python_versionto"3.12"once the repo drops Python 3.10/3.11 support, at which point the cap can be removed.Impact
🧹 Check code qualitystep in.github/workflows/test.yml).mainfor any contributor whose branch doesn't already have a pinned numpy in a local venv.Environment
python_version = "3.10")roboflow/roboflow-python, currentmain