python312Packages.scipy: use numpy.coreIncludeDir

[doronbehar]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[doronbehar]

ofborg's evaluation should report no rebuilds, and so this should be good to go trivially.

[dotlambda]

Why do we need isNumpy2? Isn't lib.versionAtLeast numpy.version "2" good enough?

[doronbehar]

Why do we need isNumpy2? Isn't lib.versionAtLeast numpy.version "2" good enough?

It can become too long to condition stuff based on this. I was even thinking of demonstrating the usage of it in e.g:

diff --git i/pkgs/development/python-modules/h5py/default.nix w/pkgs/development/python-modules/h5py/default.nix
index 13a464dccb4c..53b85662007d 100644
--- i/pkgs/development/python-modules/h5py/default.nix
+++ w/pkgs/development/python-modules/h5py/default.nix
@@ -49,7 +49,7 @@ buildPythonPackage rec {
 
   # avoid strict pinning of numpy, can't be replaced with pythonRelaxDepsHook,
   # see: https://github.com/NixOS/nixpkgs/issues/327941
-  postPatch = ''
+  postPatch = lib.optionals (!numpy.isNumpy2) ''
     substituteInPlace pyproject.toml \
       --replace-fail "numpy >=2.0.0rc1" "numpy"
   '';
diff --git i/pkgs/development/python-modules/matplotlib/default.nix w/pkgs/development/python-modules/matplotlib/default.nix
index 2bcf4d246c45..a372aaa228dc 100644
--- i/pkgs/development/python-modules/matplotlib/default.nix
+++ w/pkgs/development/python-modules/matplotlib/default.nix
@@ -109,9 +109,10 @@ buildPythonPackage rec {
   # With the following patch we just hard-code these paths into the install
   # script.
   postPatch =
-    ''
+    lib.optionalString (!numpy.isNumpy2) ''
       substituteInPlace pyproject.toml \
         --replace-fail '"numpy>=2.0.0rc1,<2.3",' ""
+    '' + ''
       patchShebangs tools
     ''
     + lib.optionalString (stdenv.isLinux && interactive) ''

But I'm not sure if you'll like this. The same can be done for scipy, but there it may trigger rebuilds.

[dotlambda]

That substituteInPlace can be applied unconditionally, which is better anyway because it makes sure it still applies when matplotlib is updated.

[doronbehar]

That substituteInPlace can be applied unconditionally, which is better anyway because it makes sure it still applies when matplotlib is updated.

OK that makes sense. In #338334 it was useful to apply that substitution conditionally, in order to catch multiple conflicting numpys in the PYTHONPATH before building, but that is now less relevant.