BUG: Not NumPy 2.0 compatible

[larsoner]

Modules need to be rebuilt and released now that NumPy 2.0 EDIT: RC1 is out. Importing current cftime from PyPI I get on Linux:

>>> import cftime

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.1.0.dev0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Traceback (most recent call last):  File "<stdin>", line 1, in <module>
  File "/home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/cftime/__init__.py", line 1, in <module>
    from ._cftime import (datetime, real_datetime,
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/larsoner/python/virtualenvs/base/lib/python3.11/site-packages/cftime/__init__.py", line 1, in <module>
    from ._cftime import (datetime, real_datetime,
  File "src/cftime/_cftime.pyx", line 1, in init cftime._cftime
ImportError: numpy.core.multiarray failed to import (auto-generated because you didn't call 'numpy.import_array()' after cimporting numpy; use '<void>numpy._import_array' to disable if you are certain you don't need it).

See also numpy/numpy#24300 (comment)

[ocefpaf]

Numpy 2.0 is not out! There is a release candidate version for testing but the stable one isn't published yet. See https://pypi.org/project/numpy/#history.

[larsoner]

Correct it's not out but the most recent advice from the linked thread is:

With numpy 2.0.0rc1 available, everyone can start doing their 2.0-compatible releases!

[ocefpaf]

Sure. Do you want to send a PR to add that to our testing?

PS: I'm from a time when building stable releases with unstable Software was unwise. However, nowadays all major libraries only releases unstable RCs and requests others to ignore that fact and work with it.

[larsoner]

Sure. Do you want to send a PR to add that to our testing?

Looks like you do already test against 2.0:

cftime/.github/workflows/tests_latest.yml

Lines 27 to 30 in d549c09

	python -m pip install \
	--index-url https://pypi.anaconda.org/scientific-python-nightly-wheels/simple/ \
	--trusted-host pypi.anaconda.org \
	--no-deps --pre --upgrade \

And your pyproject.toml is nearly set up to build against NumPy 2.0:

cftime/pyproject.toml

Line 7 in d549c09

"numpy>=2.0.0rc1,<3 ; python_version >= '3.9'",

More than testing, then, what's really needed I think are wheels on PyPI that are 2.0-compatible. So I'll open a PR to make the relevant change to your cibuildwheel run and maybe a release after that would make things future compatible?

I'm from a time when building stable releases with unstable Software was unwise. However, nowadays all major libraries only releases unstable RCs and requests others to ignore that fact and work with it.

Yeah not sure about other packages, but at least in the case of NumPy they have said more or less that the purpose of the RC1 is to allow people time to build and release their packages before 2.0 lands (in a couple/few weeks?) and breaks packages that didn't have an existing numpy<2 pin in their requirements. So it's a bit odd perhaps but the guidance in this case seems clear enough and hopefully not too hard to follow!

[ocefpaf]

It was not my PR that added it. I would not publish it until a stable version is out though.

[larsoner]

I would not publish it until a stable version is out though.

Okay. This goes against the advice of the NumPy devs, though. And what you have on PyPI currently will lead to import failures once NumPy 2.0 stable does land, as there is no version protection on that release like numpy < 2.0.

[valeriupredoi]

I think this is solved by #319 folks - any idea when will a cftime=1.6.4 be out that'll include that fix, please? 🍺