Bump numpy from 2.2.4 to 2.4.3 in /requirements

[dependabot]

Bumps numpy from 2.2.4 to 2.4.3.

Release notes

Sourced from numpy's releases.

2.4.3 (Mar 9, 2026)

NumPy 2.4.3 Release Notes

The NumPy 2.4.3 is a patch release that fixes bugs discovered after the 2.4.2 release. The most user visible fix may be a threading fix for OpenBLAS on ARM, closing issue #30816.

This release supports Python versions 3.11-3.14

Contributors

A total of 11 people contributed to this release. People with a "+" by their names contributed a patch for the first time.

• Antareep Sarkar +
• Charles Harris
• Joren Hammudoglu
• Matthieu Darbois
• Matti Picus
• Nathan Goldbaum
• Peter Hawkins
• Pieter Eendebak
• Sebastian Berg
• Warren Weckesser
• stratakis +

Pull requests merged

A total of 14 pull requests were merged for this release.

• #30759: MAINT: Prepare 2.4.x for further development
• #30827: BUG: Fix some leaks found via LeakSanitizer (#30756)
• #30841: MAINT: Synchronize 2.4.x submodules with main
• #30849: TYP: matlib: missing extended precision imports
• #30850: BUG: Fix weak hash function in np.isin(). (#30840)
• #30921: BUG: fix infinite recursion in np.ma.flatten_structured_array...
• #30922: BUG: Fix buffer overrun in CPU baseline validation (#30877)
• #30923: BUG: Fix busdaycalendar's handling of a bool array weekmask....
• #30924: BUG: Fix reference leaks and NULL pointer dereferences (#30908)
• #30925: MAINT: fix two minor issues noticed when touching the C API setup
• #30955: ENH: Test .kind not .char in np.testing.assert_equal (#30879)
• #30957: BUG: fix type issues in uses if PyDataType macros
• #30958: MAINT: Don't use vulture 2.15, it has false positives
• #30973: MAINT: update openblas (#30961)

2.4.2 (Feb 1, 2026)

NumPy 2.4.2 Release Notes

The NumPy 2.4.2 is a patch release that fixes bugs discovered after the 2.4.1 release. Highlights are:

... (truncated)

Changelog

Sourced from numpy's changelog.

This is a walkthrough of the NumPy 2.4.0 release on Linux, which will be the first feature release using the numpy/numpy-release <https://github.com/numpy/numpy-release>__ repository.

The commands can be copied into the command line, but be sure to replace 2.4.0 with the correct version. This should be read together with the :ref:general release guide <prepare_release>.

Facility preparation

Before beginning to make a release, use the requirements/*_requirements.txt files to ensure that you have the needed software. Most software can be installed with pip, but some will require apt-get, dnf, or whatever your system uses for software. You will also need a GitHub personal access token (PAT) to push the documentation. There are a few ways to streamline things:

• Git can be set up to use a keyring to store your GitHub personal access token. Search online for the details.

Prior to release

Add/drop Python versions

When adding or dropping Python versions, multiple config and CI files need to be edited in addition to changing the minimum version in pyproject.toml. Make these changes in an ordinary PR against main and backport if necessary. We currently release wheels for new Python versions after the first Python RC once manylinux and cibuildwheel support that new Python version.

Backport pull requests

Changes that have been marked for this release must be backported to the maintenance/2.4.x branch.

Update 2.4.0 milestones

Look at the issues/prs with 2.4.0 milestones and either push them off to a later version, or maybe remove the milestone. You may need to add a milestone.

Check the numpy-release repo

... (truncated)

Commits

• 8bcb2e7 Merge pull request #30974 from charris/prepare-2.4.3
• 9a2b5ee REL: Prepare for the NumPy 2.4.3 release
• a822ac2 Merge pull request #30973 from charris/backport-30961
• 039bf54 MAINT: update openblas (#30961)
• 254bafa Merge pull request #30955 from charris/backport-30879
• 0cc7d38 ENH: Test .kind not .char in np.testing.assert_equal (#30879)
• 9ee571d Merge pull request #30957 from charris/backport-30918
• f302a16 Merge pull request #30958 from charris/backport-30938
• d240a09 MAINT: Don't use vulture 2.15, it has false positives
• 4fc08e9 MAINT: Don't use vulture 2.15, it has false positives
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[adamjstewart]

@qubvel we need to make some decisions here.

Currently we support Python 3.9+ and test 3.10–3.12. Python 3.9 is officially EOL, and many of our dependencies like numpy only support Python 3.12+. If we want testing to remain simple and easy, I would propose following numpy's Python support schedule and only support/test Python 3.12+. Otherwise we will need to add Python-version-specific requirement.txts or not test older versions.

Let me know what you think and I'll make the updates to pyproject.toml/tests.yaml/requirements.txt. We could also consider switching to uv.lock; @isaaccorley did this in torchgeo/torchgeo#3444 and it's been working well for us.

[qubvel]

I don't wanna bump to python 3.12+ as a hard requirement, the error is clear and I would let user to decide which combination python+numpy to use. On our side I would prefer to drop testing for older python versions, wdyt?

[adamjstewart]

I'm fine with that. But note that we may get bug reports from users trying to use old versions that we aren't able to test in CI. For example, if I add some fancy new type hint thing, it may not work for them, and we have no way of knowing until they open a bug report.

So I guess I would propose testing Python 3.12–3.14 (SPEC 0) and officially supporting Python 3.10+ (non-EOL versions)?

[qubvel]

@dependabot rebase