Support NumPy 2

[DanielYang59]

Summary

• Support NumPy 2
• Test both NumPy 1 and NumPy 2
• pytest workflow only show top 20 duration instead of all, otherwise the log page is too long to navigate through

Future PR

• Completely migrate to pyproject.toml

[DanielYang59]

@ml-evs It seems unit test are passing for both numpy 1 and numpy 2, is there any reason to pin numpy < 2 that I missed?

The test failure in auto-gen-release should be owing to restricted access to repo secrets from a fork:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

Type:     clojure.lang.ExceptionInfo
Message:  Expected environment variable to be set: GITHUB_TOKEN
Data:     {:env/name "GITHUB_TOKEN"}
Location: /var/src/release-on-push-action/src/release_on_push_action/core.clj:13:7

[ml-evs]

@ml-evs It seems unit test are passing for both numpy 1 and numpy 2, is there any reason to pin numpy < 2 that I missed?

Not that I know of, though can imagine that test coverage isn't good enough to say for sure. I'm happy to merge this and see if anything breaks downstream

[DanielYang59]

Not that I know of, though can imagine that test coverage isn't good enough to say for sure.

Thanks for your reply, in pymatgen we have seen a lot of numpy2 compatible issues surrounding cython code for Windows as the default int type changed for Windows in Numpy 2, but it seem there's no cython code for matminer?

[ml-evs]

Thanks for your reply, in pymatgen we have seen a lot of numpy2 compatible issues surrounding cython code for Windows as the default int type changed for Windows in Numpy 2, but it seem there's no cython code for matminer?

Not that I'm aware of, so let's just remove it (as you have done).

Thanks for this!

[DanielYang59]

no problem, thanks for reviewing. I might push another PR to completely migrate setup.py to pyproject.toml, is there any reason not to migrate at this moment?

[ml-evs]

I might push another PR to completely migrate setup.py to pyproject.toml, is there any reason not to migrate at this moment?

Only lack of time/interest -- I don't mind maintaining pyproject.toml over setup.py long term but I don't think we have enough people to support many other changes

[DanielYang59]

Cool, I will give a hand on this one