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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions