Update pyproject.toml

[mavaylon1]

Motivation

What was the reasoning behind this change? Please explain the changes briefly.

Numpy has released numpy 2.0, which came with deprecations. I'm going to pin below 2.0 for the release on April 30th.

Update: Numpy 2.0 supports python 3.9-3.12. I think we should keep this below 2.0 until October when python 3.8 is deprecated. We will fix the deprecations then, rather than make a change now and make another change in October.

How to test the behavior?

Show how to reproduce the new behavior (can be a bug fix or a new feature)

Checklist

• [x] Did you update CHANGELOG.md with your changes?
• [x] Have you checked our Contributing document?
• [x] Have you ensured the PR clearly describes the problem and the solution?
• [x] Is your contribution compliant with our coding style? This can be checked running ruff from the source directory.
• [x] Have you checked to ensure that there aren't other open Pull Requests for the same change?
• [x] Have you included the relevant issue number using "Fix #XXX" notation where XXX is the issue number? By including "Fix #XXX" you allow GitHub to close issue #XXX when the PR is merged.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 86.05%. Comparing base (f331a2e) to head (4d85507).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## dev #187 +/- ## ======================================= Coverage 86.05% 86.05% ======================================= Files 5 5 Lines 1162 1162 Branches 287 287 ======================================= Hits 1000 1000 Misses 107 107 Partials 55 55 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[mavaylon1]

Review Notes: I ran the workflow for "run all tests" and it passes everything. I did not update the changelog this is something we do not put there.

[rly]

Numpy 2.0 supports python 3.9-3.12. I think we should keep this below 2.0 until October when python 3.8 is deprecated. We will fix the deprecations then, rather than make a change now and make another change in October.

Many packages have dropped Python 3.8 support in their latest version. An alternative approach to waiting until October to support Numpy 2.0 is to update the code to work with both Numpy < 2.0 and Numpy >= 2.0 (I don't think they would conflict), allow both in the requirements, and set up requirements.txt to use a version of Numpy < 2.0 for Python 3.8 and the latest Numpy >= 2.0 version for other versions. Like in https://github.com/hdmf-dev/hdmf/blame/95ba8765af25b0ffce0f20c28b047eb1616873a5/requirements.txt

[mavaylon1]

Numpy 2.0 supports python 3.9-3.12. I think we should keep this below 2.0 until October when python 3.8 is deprecated. We will fix the deprecations then, rather than make a change now and make another change in October.

Many packages have dropped Python 3.8 support in their latest version. An alternative approach to waiting until October to support Numpy 2.0 is to update the code to work with both Numpy < 2.0 and Numpy >= 2.0 (I don't think they would conflict), allow both in the requirements, and set up requirements.txt to use a version of Numpy < 2.0 for Python 3.8 and the latest Numpy >= 2.0 version for other versions. Like in https://github.com/hdmf-dev/hdmf/blame/95ba8765af25b0ffce0f20c28b047eb1616873a5/requirements.txt

Third option is to (for the releases tomorrow) just do this. Then do the release, then try to see if a middle ground for numpy 2.0 and below.

[oruebel]

Changing the requirements to have different Numpy versions for different Python versions seems simple enough. I assume this would be just something like:

numpy>=1.24, <2.0';python_version<='3.8'   # pin below 2.0 until python 3.8 is deprecated
numpy>=1.24;python_version>'3.8'

[mavaylon1]

Changing the requirements to have different Numpy versions for different Python versions seems simple enough. I assume this would be just something like:

numpy>=1.24, <2.0';python_version<='3.8'   # pin below 2.0 until python 3.8 is deprecated

numpy>=1.24;python_version>'3.8'

So no matter what python version, we will get the error from numpy because np.string_ is called in the objectmapper but that is now deprecated.

I still standby pinning below 2.0 for the release, then finding all the areas we need fixed to support numpy 2.0.