Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Interesting. Runtime selection would definitely be nice. A couple of questions:

• Now that openblas is removed from build-time and runtime dependencies, how does conda know to install it or one of the other alternatives?
• There is no runtime selection API in numpy itself (we'd like to have that, but that's a bit more work ...), so it's not really runtime right? More like install time.
• What is the order of preference if multiple BLAS versions are detected? The numpy.distutils order is MKL, BLIS, OpenBLAS, ATLAS, Accelerate, as defined here. (that's for build-time selection in the absence of a site.cfg)
• Isn't it tricky to not pin OpenBLAS? OpenBLAS isn't exactly known for being stable ....

Now that openblas is removed from build-time and runtime dependencies, how does conda know to install it or one of the other alternatives?

libblas package in host automatically adds the dependency to run

There is no runtime selection API in numpy itself (we'd like to have that, but that's a bit more work ...), so it's not really runtime right? More like install time.

Right, install time.

What is the order of preference if multiple BLAS versions are detected? The numpy.distutils order is MKL, BLIS, OpenBLAS, ATLAS, Accelerate, as defined here. (that's for build-time selection in the absence of a site.cfg)

OpenBLAS is installed by default on linux and MKL on windows. You can select what you want by doing,

1. blas=*=mkl
2. blas=*=openblas
3. blas=*=blis
4. blas=*=netlib

Isn't it tricky to not pin OpenBLAS? OpenBLAS isn't exactly known for being stable ....

We are pinning to libblas 3.* and liblapack 3.8.* and the library libblas=3.8.0=openblas pins openblas exactly. If the next openblas version is compatible with libblas 3.8.0, then we will update the openblas version at https://github.com/conda-forge/blas-feedstock/blob/master/recipe/meta.yaml#L53

Btw, you can't install multiple libblas packages in one environment, just one. You can install openblas, mkl into 1 environment, but numpy will pick up the blas library corresponding to the libblas package.

Numpy will link to libblas.so and libcblas.so and the libblas conda package (there are 4 variants of this libblas conda package) is just a symlink from libblas.so to the specific installation.

Thanks, that all sounds good!

Not a WIP anymore. Ready for review

@rgommers, does numpy need CBLAS or just BLAS? Also it doesn't need a C++ compiler right? (Just a C compiler)

I'm going to merge this. (CBLAS and C++ compiler is not a huge issue. Only adds a couple of MBs. We can revisit later)

Thanks @ocefpaf, @rgommers for the review

A C++ compiler is not needed.

CBLAS is needed. This comment in site.cfg.example may be helpful, not sure if BLIS is built like that in conda-forge:

#   - the CBLAS interface (needed by NumPy) isn't built by default; define
#     BLIS_ENABLE_CBLAS to build it.

Thanks. All providers are built with CBLAS, so there's no issue there.
I had to add liblapack as well to prevent numpy in OSX from choosing Accelerate. (#149)

Ah yes. Accelerate will probably be dropped soon (SciPy already has dropped it).

numpy/numpy#13132 was just opened a few days ago to improve the BLAS/LAPACK selection mechanism, should be in 1.17.0