This appears to be needed in some Python distutils for the library to
get on RPATH correctly. I’m not sure why this worked before, but I
needed this value set for Python 3.8 numpy to work correctly.
numpy has added hypothesis as a dependency for running property-based
tests:
https://github.com/numpy/numpy/pull/15189
However, hypothesis is not an input of the derivations. And thus tests
have been failing with:
ERROR .. - ModuleNotFoundError: No module named 'hypothesis'
https://hydra.nixos.org/build/124613306/nixlog/1
This change adds hypothesis to checkInputs, so that tests are run
again.
When using netlib lapack/blas, the section name doesn’t match what
numpy expects. So we need to add extra sections for both so that the
right directory is found. The original “blas.implementation” section
may not actually be still required, but it is still a good idea so
that numpy know whether to apply any blas-implementation specific
quirks.
Fixes#86613
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
Patching numpy.distutils used to be required for pythonPackages.cython
to build on darwin. It was later accidentally disabled during one of the
refactorings, but that did not break cython. This change reinstantiates
the patch. It still applies, so it should be low maintenance and it can
still be useful.
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.
Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.
Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
