Review if we need to refactor for numpy >=2.1.0

[ReimarBauer]

currently we not have set a pinning for numpy but our dependencies have.

We need to check if we are compatible when they release their pinning.

[sarthakvyas16]

By monitoring releases, creating a robust testing strategy, and potentially pinning compatible versions, you can maintain compatibility with your dependencies as they update their pinning for NumPy. This proactive approach will help avoid issues when new versions are released.

[ReimarBauer]

We do have a scheduled test to see when incompatible API changes happen. When you look at a pixi.lock file of a recent installation and grep for numpy you do see the work for the solver. Some of our dependencies have already set a pinning. When basemap-data changes its pinning, we will find if others have to have a pinning.

      - conda: https://conda.anaconda.org/conda-forge/linux-64/numpy-1.26.4-py311h64a7726_0.conda
  - numpy >=1.26,<1.27.0a0
  - numpy >=1.26.4,<2.0a0
  - numpy >=1.19,<3
  - numpy >=1.19,<3
  - numpy >=1.23
  - numpy
  - numpy >=1.19,<3
  - numpy >=1.21
  - numpy >=1.20
  - numpy >=1.19,<3
  name: numpy
  url: https://conda.anaconda.org/conda-forge/linux-64/numpy-1.26.4-py311h64a7726_0.conda
  - numpy-base <0a0
  - numpy >=1.19,<3
  - numpy >=1.22.4
  - numpy >=1.23
  - numpy <2.3
  - numpy >=1.19,<3
  - numpy >=1.23.5
  - numpy >=1.19,<3
  - numpy
  - numpy >=1.24

[sarthakvyas16]

These version constraints are quite important because they affect the stability of our application. As you mentioned, there are multiple version constraints for NumPy across different dependencies.

Do you think we should summarize these constraints in a compatibility matrix? This would help us understand how to handle other dependencies when basemap-data changes its pinning.

And yes, the URL for NumPy is also helpful, as it ensures that we are downloading the correct version. Have you faced any issues when updating the pinning for a specific package?

[ReimarBauer]

Sometimes we have to pin a module until some other package has fixed some issues. I expect this here too.

Copying the whole section, it is basemap. basemap-data is a subpackage of it. I readed that not correctly before.

  name: basemap
  version: 1.4.1
  build: np126py311hb1fe3e7_0
  subdir: linux-64
  url: https://conda.anaconda.org/conda-forge/linux-64/basemap-1.4.1-np126py311hb1fe3e7_0.conda
  sha256: 3d57e7b295c497c058ac2041e0a78fe031eb4e2a0389121b1e047c8a4b3db8d0
  md5: de782d1601055a3a00ec2434bb597407
  depends:
  - basemap-data
  - geos >=3.12.1,<3.12.2.0a0
  - libgcc-ng >=12
  - libstdcxx-ng >=12
  - matplotlib-base >=1.5,<3.9
  - numpy >=1.26,<1.27.0a0
  - numpy >=1.26.4,<2.0a0
  - pyproj >=1.9.3,<3.7.0
  - pyshp >=1.2.0,<2.4.0
  - python >=3.11,<3.12.0a0
  - python_abi 3.11.* *_cp311
  license: MIT
  license_family: MIT
  size: 193978
  timestamp: 1708019032522

I am one of the maintainers of that package on conda-forge.
At the moment we build a new basemap we have to check for that package if we need to pin it.

Numpy 2.0 was released in June 2024. The basemap 7 months and 26 days ago. The current pinning comes from the version on conda-forge at that time.

Helpful for MSS would be to see the release date of all dependencies and if there are newer versions than we momentanly can use. I've not seen something which can be automated done. And I would expect such a feature on conda-forge or a similiar platform. Because you then want to look also in the dependencies of one dependency.

[ReimarBauer]

Whether we do set a pinning on our own, we should also check if our usage is compatible to the most recent numpy version. And when there are changes needed they can be done in a way that we are prepared but still can use the old version.

look for import numpy as np

In case we need a pinning, we would do this in stable.

[sarthakvyas16]

Absolutely, I agree! It’s crucial that we ensure compatibility with the latest NumPy version, even if we decide to set our own pinning. This proactive approach will help us prepare for any necessary changes while still allowing us to use the older version without issues.

I’ll make sure to check the usage of import numpy as np throughout our codebase to identify any potential areas that might require updates when we move to the newer version.

Setting the pinning in a stable manner sounds like a solid plan. Do you have any specific versioning strategies in mind for this process?

Looking forward to your thoughts!

[sarthakvyas16]

will you select me for GSoC 2024 for your Organisation?

[ReimarBauer]

This depends on your proposal if you mean 2025. GSOC2024 is finished.

Selections of organization have not started.

[sarthakvyas16]

Thank you......So what should I do to get selected? For 2025.