Skip to content

Lift numpy<2.0 cap in requirements_base.txt #1200

@yizhou-wang

Description

@yizhou-wang

Summary

Request to lift the numpy<2.0.0 upper cap added in #1117 so that nuscenes-devkit can be installed in environments that depend on numpy>=2.x.

The cap currently lives at setup/requirements/requirements_base.txt:

numpy>=1.22.0,<2.0.0

Why this matters now

The cap was added in #1117 to work around a transitive ABI break: a module compiled against NumPy 1.x couldn't import under NumPy 2.x without being rebuilt. That was the right call in September 2024 when most of the scientific-Python ecosystem hadn't yet released NumPy-2-compatible wheels.

A year-and-change later, NumPy 2.x wheels are widely available across the existing direct dependencies in requirements_base.txt:

Package NumPy 2.x support landed in Current requirements_base.txt lower bound
matplotlib 3.8.0 (Sep 2023) >=3.6.0
opencv-python-headless 4.10.x (Jun 2024) >=4.5.4.58
scipy 1.13.0 (Apr 2024) (no pin)
Shapely 2.0.4 (Apr 2024) ~=2.0.3
pyquaternion pure-Python, no compiled deps >=0.9.5
scikit-learn 1.5.0 (May 2024) (no pin)
descartes pure-Python (no pin)
Pillow every recent release >6.2.1

Because every direct dep already has a NumPy-2-compatible release at or above its current lower bound, simply removing the upper cap should let pip resolve a working environment on NumPy 2.x without any further changes to lower bounds. The tracking extra (motmetrics==1.4.0, pandas>=0.24) is similarly fine — motmetrics 1.4.0 and pandas 2.2.2+ both work with NumPy 2.x.

Concrete user impact

Downstream packages that legitimately want NumPy 2.x can't co-install nuscenes-devkit. A common example is trackeval (HOTA / CLEAR / Identity tracking metrics, JonathonLuiten/TrackEval and its PyPI republish). The current PyPI trackeval==1.3.0 declares:

numpy>=2.0.2; python_version=='3.9'
numpy>=2.2.6; python_version=='3.10'
numpy>=2.3.2; python_version>='3.11'

Combined with nuscenes-devkit's numpy<2.0.0, the intersection is empty on any Python ≥ 3.9 and pip refuses to resolve. The runtime is actually fine (forcing both packages together with numpy==1.26.4 works), so the conflict is purely a metadata one — but it still blocks clean pip install in CI for any project that needs both libraries.

Proposed change

Replace

numpy>=1.22.0,<2.0.0

with

numpy>=1.22.0

in setup/requirements/requirements_base.txt.

If you'd prefer a more conservative bump (e.g. numpy>=1.22.0,<3.0.0) to leave room for a future NumPy 3.x review, that also unblocks the resolver while keeping a forward-compat guardrail.

Thanks for maintaining this!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions