| 26 Jun 2026 |
 Vladimír Čunát | The variable shouldn't hurt to have everywhere in builds (by default), no? | 13:51:33 |
 hexa | and they do it via blas I think | 13:51:43 |
| Vladimír Čunát | * The variable shouldn't hurt to have everywhere in builds (by default), no? Or possibly just in the check phases. | 13:52:29 |
 emily | probably not, and I could see an argument for "we should just set every relevant environment variable for ~everything in stdenv". but that might be an annoying practice to follow in general, e.g. would turn various kinds of flag changes into world rebuilds. and then it doesn't scale if you also need to say, point something at a path or whatever (which mpiCheckPhaseHook also happens to do) | 13:53:02 |
 Grimmauld (any/all) | add mpiCheckPhaseHook to blas propagatedBuildInputs ? | 13:53:08 |
| emily | so feels like doing it closer to the problem makes sense by default | 13:53:25 |
| emily | not sure what it is with Python things and using all the cores all the time | 13:53:52 |
| hexa | default numpy/scipy behavior | 13:54:10 |
| hexa | they scale right up | 13:54:16 |
| Grimmauld (any/all) | python has checks-by-default, and numpy/scipy abstracts away the compute cost of tests | 13:54:20 |
| emily | right | 13:54:25 |
| hexa | the real deal would be faking nproc for builds | 13:55:03 |
| emily | probably just adding setup hooks to those is sufficient then? or the Python check phase could yell at you if it sees them in the dep graph but not a corresponding hook… | 13:55:18 |
| Vladimír Čunát | IIRC cgroups only allow you to pin to particular subset of cores. | 13:56:24 |
| Vladimír Čunát | * IIRC cgroups only allow you to restrict to particular subset of cores. | 13:56:43 |
| Vladimír Čunát | * IIRC cgroups only allow you to restrict to a particular subset of cores. | 13:56:50 |
| emily | the real real deal would be NumPy supporting jobserver protocol and also jobserver protocol being good | 13:56:55 |
| Grimmauld (any/all) | diff --git a/pkgs/by-name/bl/blas/package.nix b/pkgs/by-name/bl/blas/package.nix
index 01ad1839c339..85e2e2cb3412 100644
--- a/pkgs/by-name/bl/blas/package.nix
+++ b/pkgs/by-name/bl/blas/package.nix
@@ -3,6 +3,7 @@
stdenv,
lapack-reference,
openblas,
+ mpiCheckPhaseHook,
isILP64 ? false,
blasProvider ? openblas,
}:
@@ -186,6 +187,10 @@ stdenv.mkDerivation {
"dev"
];
+ propagatedBuildInputs = [
+ mpiCheckPhaseHook
+ ];
+
meta = (blasProvider'.meta or { }) // {
description = "${lib.getName blasProvider} with just the BLAS C and FORTRAN ABI";
};
diff --git a/pkgs/development/python-modules/numpy/2.nix b/pkgs/development/python-modules/numpy/2.nix
index 67c60475fd5f..0fc2a30f3555 100644
--- a/pkgs/development/python-modules/numpy/2.nix
+++ b/pkgs/development/python-modules/numpy/2.nix
@@ -91,7 +91,6 @@ buildPythonPackage (finalAttrs: {
# see https://github.com/OpenMathLib/OpenBLAS/issues/2993
preConfigure = ''
sed -i 's/-faltivec//' numpy/distutils/system_info.py
- export OMP_NUM_THREADS=$((NIX_BUILD_CORES > 64 ? 64 : NIX_BUILD_CORES))
'';
buildInputs = [
diff --git a/pkgs/development/python-modules/scipy/default.nix b/pkgs/development/python-modules/scipy/default.nix
index cdecd986e4ef..30999320f1e8 100644
--- a/pkgs/development/python-modules/scipy/default.nix
+++ b/pkgs/development/python-modules/scipy/default.nix
@@ -190,11 +190,6 @@ buildPythonPackage (finalAttrs: {
'';
preCheck = ''
- export OMP_NUM_THREADS=$(( $NIX_BUILD_CORES / 4 ))
- if [ $OMP_NUM_THREADS -eq 0 ]; then
- export OMP_NUM_THREADS=1
- fi
-
cd $out
'';
i guess? | 13:57:17 |
| emily | (or operating systems being good but then we'd be out of a job) | 13:57:26 |
| emily | I think it won't propagate further than one layer. | 13:57:44 |
| Grimmauld (any/all) | python dependencies are fully propagated | 13:58:01 |
| Grimmauld (any/all) | oh wait indeed blas isn't a propagated dep though | 13:58:19 |
| emily | oh right | 13:58:10 |
| Grimmauld (any/all) | sorry | 13:58:21 |
| emily | probably just putting the hook in propagatedNativeBuildInputs of NumPy is the way. (wondering what the difference between OpenMP and MPI actually is…) | 13:58:52 |
| Grimmauld (any/all) | multi-core vs multi-node afaiu | 13:59:41 |
| emily | maybe we should have an openmpCheckPhaseHook that mpiCheckPhaseHook propgates then :P | 14:00:04 |
| Grimmauld (any/all) | but yeah, throwing it in propagatedNativeBuildInputs of numpy sounds like a plan a little less drastic than just throwing it in stdenv | 14:00:21 |
| emily | fwiw, OMP_NUM_THREADS turns up a surprising number of non-Python things | 14:00:25 |
| emily | looks like BLAS/LAPACK stuff. so maybe putting a hook in there is a good idea too. | 14:00:41 |
