CI typecheck fails: numpy 2.5.0 stubs use PEP 695 `type` statements, incompatible with `mypy python_version = "3.10"`

[davidnichols-ops]

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:

  numpy>=1.18.5
  

• 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

[davidnichols-ops]

Opened #499 to address this. Caps numpy<2.5 in the [dev] extra only (not in requirements.txt), so runtime installs stay unconstrained for end users while CI typecheck keeps passing. Verified make check_code_quality passes with the cap in place.

[davidnichols-ops]

Update: closing #499 in favor of #495, which includes the same numpy<2.5 dev cap in commit a4c0891. That PR is approved with all CI green, so this issue should be resolved when it merges.

[davidnichols-ops]

Closing — resolved by #495 (commit a4c0891), which capped numpy<2.5 in requirements.txt and merged to main on July 2. The mypy typecheck is no longer broken by numpy 2.5.0 stubs.