Bump pydantic

[liamhuber]

To latest on conda-forge, with upper bound for the next minor release (3.14)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[liamhuber]

AttributeError: np.string_was removed in the NumPy 2.0 release. Usenp.bytes_ instead.

[jan-janssen]

It is in the meshio package, where I unfortunately do not have control to fix it:

Traceback (most recent call last):
  File "/home/runner/miniconda3/envs/preprocessing/bin/meshio", line 6, in <module>
    from meshio._cli import main
  File "/home/runner/miniconda3/envs/preprocessing/lib/python3.12/site-packages/meshio/__init__.py", line 1, in <module>
    from . import (
  File "/home/runner/miniconda3/envs/preprocessing/lib/python3.12/site-packages/meshio/med/__init__.py", line 1, in <module>
    from ._med import read, write
  File "/home/runner/miniconda3/envs/preprocessing/lib/python3.12/site-packages/meshio/med/_med.py", line 31, in <module>
    numpy_void_str = np.string_("")
                     ^^^^^^^^^^
  File "/home/runner/miniconda3/envs/preprocessing/lib/python3.12/site-packages/numpy/__init__.py", line 778, in __getattr__
    raise AttributeError(
AttributeError: `np.string_` was removed in the NumPy 2.0 release. Use `np.bytes_` instead.

In general the NFDI benchmark is unfortunately not updated very frequently.

[liamhuber]

np.string doesn't actually appear in this repo. Taking a closer look at the stack trace, the problem comes from the call

File "/home/runner/miniconda3/envs/preprocessing/lib/python3.12/site-packages/meshio/med/_med.py", line 31, in <module>
    numpy_void_str = np.string_("")

Indeed, the meshio feedstock puts no pins on numpy at all. The pyproject file pins only a lower-bound. This environment ought not to have resolved, but meshio is just being too relaxed with its requirements.

Updating the demo to not use meshio is beyond my authority here.

I was confused why a pydantic bump would cause a numpy compatibility issue, so I looked into the failure log more deeply, and at the step "Run conda-incubator/setup-miniconda@v4", we're still getting numpy 1.x:

+ numpy                                    1.26.4  py312heda63a1_0          conda-forge       7MB

Yet the stack trace message is a v1/v2 error. Aha, because in "Create additional Conda environments" we install

numpy-2.4.6          | 8.4 MB    |            |   0% 

These are built off example_workflows/nfdi/source/envs/*. I still don't understand why the pydantic bump here would suddenly cause a failure there -- those files place no pins on numpy, so it should have been free to get v2 and cause this error long ago.

Looking in the same place at the most recent passing actions log, "Create additional Conda environments" was installing numpy v1:

 numpy-1.26.4         | 6.7 MB    |            |   0% 

That was just last week, so I have no idea what changed between now and then.

[liamhuber]

It is in the meshio package, where I unfortunately do not have control to fix it:

Ah, you're speedy! You got back to me while I was digging into it.

I found this too. What I don't understand is why it didn't fail earlier! I guess a pragmatic solution would be to add numpy pins in the nfdi envs?