Hi, I'm a Spack developer and I've been playing around with our numpy package for awhile now. One issue that we've continually faced is the inability to tell numpy which BLAS/LAPACK library we want to build with. We will create a site.cfg like:

[openblas]
libraries=openblas
library_dirs=/Users/Adam/spack/opt/spack/darwin-mojave-x86_64/clang-10.0.1-apple/openblas-0.3.6-3yts3o25cqf437oxaa4qzfhiw3swc7j2/lib
rpath=/Users/Adam/spack/opt/spack/darwin-mojave-x86_64/clang-10.0.1-apple/openblas-0.3.6-3yts3o25cqf437oxaa4qzfhiw3swc7j2/lib

which works great... unless MKL is installed on the system, in which case numpy decides to use that instead. Inevitably, the rpath isn't set (because we were never trying to build with MKL), and this leads to many problems at runtime. Some examples:

• py-numpy linking to intel mkl while compiling with gcc and openblas? spack/spack#5327
• Installing py-matplotlib fails spack/spack#6634
• scipy build fails for python 3.5 and 3.6 spack/spack#8616
• Installation issue: py-scipy spack/spack#10361
• Importing the multiarray numpy extension module failed #8653

Recently, we discovered a hack, where we can use a site.cfg like:

[openblas]
libraries=openblas
library_dirs=/Users/Adam/spack/opt/spack/darwin-mojave-x86_64/clang-10.0.1-apple/openblas-0.3.6-3yts3o25cqf437oxaa4qzfhiw3swc7j2/lib
rpath=/Users/Adam/spack/opt/spack/darwin-mojave-x86_64/clang-10.0.1-apple/openblas-0.3.6-3yts3o25cqf437oxaa4qzfhiw3swc7j2/lib
[mkl]
libraries=
library_dirs=
rpath=
[atlas]
libraries=
library_dirs=
rpath=

to prevent numpy from looking for MKL or ATLAS elsewhere. This worked fine, until the release of numpy 1.17.0, when we noticed build failures for numexpr: pydata/numexpr#340

It seems like this isn't the right way to do things. So is there a better way to tell numpy which BLAS/LAPACK implementation to use?

@scheibelp @huqy @robbmcleod @scottwittenburg @s-sajid-ali