Numpy 2.0

[CasperSchippers]

Soon, Numpy will release a version 2.0 with some breaking changes with respect to version 1.x.
https://numpy.org/devdocs/release/2.0.0-notes.html
https://numpy.org/devdocs/numpy_2_0_migration_guide.html

We should check (and try to fix of course) if there are any incompatibilities for us.

[BenediktBurger]

Thanks for raising this issue.

Unfortunately there is no release of numpy 2.0.0 yet to test it, as a test environment will catch a few issues.

As a first measure, we could add numpy < 2.0.0 to our requirements, until we know, that we are compatible.

As almost all changes are backward compatible, we can remove that requirement, once we are satisfied (and have tested with numpy 2).

A quick check with grep "np\." did not reveal anything.

[CasperSchippers]

I misread and thought that the first release candidates should be out already, but the first RC is planned for 1 February I think, so at that time we should be abble to get a better idea if there are things we should fix.
Maybe it's best to wait with any changes until then (also to the requirements, as I don't expect we'll release another version prior to the new numpy version, so adding this now will have little impact).

(PS Open question: would it be a good idea to add, at that time, numpy < 3.0.0 to the requirements, and maybe something similar to other the other packages?)

[CasperSchippers]

I did quickly check with the ruff NPY201 rule that is being prepared for this occasion, and only found two instances of NaN, which will be replaced by nan. I already made a PR which fixes this, but suggest to only have a further look once the RC drops.

[bilderbuchi]

Thanks for raising this! A numpy RC is imminent I think. (detailed upstream issue with some discussions of finer points: numpy/numpy#24300)
Yes, bounding the dependency to numpy <3 seems like a smart idea.

[bilderbuchi]

From numpy/numpy#24300 (comment)

For (2), note that there are a ton of packages that do not have correct upper bounds, so if you haven't done your own new release that is compatible with both 2.0.0 and 1.26.x before 2.0.0 comes out, the users of your project are likely to have a hard time.

At this point I don't know (and don't have the time to ascertain) if we are impacted by this -- I'm guessing that if our test suite just passes with numpy 2.0.0b1 without modifications, we are in the clear, but it might be worthwhile to adjust this upper bound correctly in any case?

@CasperSchippers can you finish/merge #1026?

[CasperSchippers]

I see that b1 has just been released. Will try to look at it further this week/weekend.

Based on what I've seen so far, it should be quite doable to get this fixed before 2.0.0 is released.

[CasperSchippers]

Now numpy 2.0.0b1 has been released, i've started check the compatibility and, obviously, ran immediattely into an issue doing so.
Pandas is not yet compatible with numpy 2.0 (also noted in pandas-dev/pandas#55519). It seems that we will be waiting for the numpy 2.0.0rc1 before this will be fixed in pandas.

At this point it is difficult to tell if there are any other issues. The ruff rule that I used before didn't find anything else, but we'll have to wait for pandas before we can know for sure.

[bilderbuchi]

numpy 2.0.0rc1 is here now: numpy/numpy#24300 (comment)

[CasperSchippers]

Indeed rc1 has been released, and now also pandas 2.2.2, which supports numpy 2 (at least the release candidate) so I could start checking the our compatibility.

I only ran into a single issue: pint is not yet compatible with numpy2. However, there is a fix in the git repo (hgrecco/pint@f2e4081), but not yet a release that includes the fix. Manually installing it from GitHub does work fine for testing however.

Apart from that (and what was fixed already in the PR) I did not yet find any incompatibilities in our code base (with a careful 🎉). All tests are running fine, the examples that I've tried so far are working fine; finally I did some manual checking and didn't find anything (though I intend to do some more).

[CasperSchippers]

I checked again and, apart from the aforementioned remarks, I think the PR is finished. Just a few remarks/questions:

• pint is only compatible with numpy 2.0 after the upcomming release; that does mean that, while we do not have any issues in our codebase, users can practically not use it due to pint at this moment. Do we need to do anything with this, or just leave it up to the user?
• Do we want to run CI tests agains numpy 2.0? Would maybe be a good idea, but increases the amount of CI.
• I've put a limit on both numpy and pandas to keep version <3. Should we also increase the minimum version number of these packages, since for both packages python>3.8 is only supported by later versions than what is listed as minimum required version now?

[BenediktBurger]

pint is only compatible with numpy 2.0 after the upcomming release; that does mean that, while we do not have any issues in our codebase, users can practically not use it due to pint at this moment. Do we need to do anything with this, or just leave it up to the user?

I'd leave it up to the user. This will resolve in the short term, I guess.

Do we want to run CI tests agains numpy 2.0? Would maybe be a good idea, but increases the amount of CI.

Maybe just for a single python version and OS version. That ensures tests, but does not add many test cases.

Should we also increase the minimum version number of these packages, since for both packages python>3.8 is only supported by later versions than what is listed as minimum required version now?

I'd leave it as is, as our codebase does not require a newer version. That shows that it is only the python version, which makes the requirements.

[bilderbuchi]

pint is only compatible with numpy 2.0 after the upcomming release; that does mean that, while we do not have any issues in our codebase, users can practically not use it due to pint at this moment. Do we need to do anything with this, or just leave it up to the user?

I'd leave it up to the user. This will resolve in the short term, I guess.

Do we want to run CI tests agains numpy 2.0? Would maybe be a good idea, but increases the amount of CI.

Maybe just for a single python version and OS version. That ensures tests, but does not add many test cases.

Should we also increase the minimum version number of these packages, since for both packages python>3.8 is only supported by later versions than what is listed as minimum required version now?

I'd leave it as is, as our codebase does not require a newer version. That shows that it is only the python version, which makes the requirements.

I agree, 👍 to all of these

[CasperSchippers]

Thanks, will do this.

One note regarding the minimum version of other packages: it is difficult to verify what version is the minumum version, since we cannot check whether the old versions work; for example, I can imagine that the fairly old pandas or numpy versions that are mentioned in the setup.cfg file, are not actually supported by our codebase, but we have no reasonable way to check this, since it is not possible to install these versions with the newer python versions.

[bilderbuchi]

One note regarding the minimum version of other packages: it is difficult to verify what version is the minumum version, since we cannot check whether the old versions work; for example, I can imagine that the fairly old pandas or numpy versions that are mentioned in the setup.cfg file, are not actually supported by our codebase, but we have no reasonable way to check this, since it is not possible to install these versions with the newer python versions.

You're probably right. Especially pandas has had its first major release in the meantime - we should probably put this to >=1 to dial in the API stability.
I try to keep the pymeasure.yml at a version status that installs on all our supported Python versions, this has worked out reasonably well most of the time, and simplifies CI maintenance as we only need one env file. I'd like to keep it this way.

We could bump dependency minimum versions to the oldest version available for the oldest Python version we support to avoid this.
However, such bumps would not typically associated with a needed change (because we use a new feature or so), and the question is if this would exclude folks that for some reason (centos? REHL? IT infra?) are on older versions -- those would probably still work, we just don't support or test this, similar to using older Python versions.
Also, we wouldn't test those versions either, because see above reason for having one env file.

Note: I miss Julia with this, it has this nice solution for exactly this problem: https://github.com/julia-actions/julia-downgrade-compat

[BenediktBurger]

However, such bumps would not typically associated with a needed change (because we use a new feature or so), and the question is if this would exclude folks that for some reason (centos? REHL? IT infra?) are on older versions -- those would probably still work, we just don't support or test this, similar to using older Python versions.

I agree, that we should keep it at the lowest version possible. We just don't check compatibility.

[CasperSchippers]

Sounds reasonable, we can keep the lowest possible version (although we're technically not entirely sure what the real lower limits are).

So, I was intrigued and went to try running the tests with the older packages; I did not completely succeed, but was supprised to see that the older numpy and pandas versions I managed to install (1.12 & 0.20, respectively) did not not seem to be the problem. Older versions I could not check, since python 3.6 is a relatively hard bottom limit, due to all the f-strings (if you discount changing a single instance of importlib.metadata to importlib_metadata which is required for python<3.8 I think).
I did find two incompatibilities, so I upped the minimum version for pyvisa and pytest (not sure if this qualifies the attempt as usefull, but oh well)

[CasperSchippers]

I'll keep this issue open, since we do need to update the numpy-2 test (requiremenst.yml) to the final versions once numpy==2.0.0 and pint>0.23 are released.