Conda: Why is environment stuck with blas 1.0

Question

Conda has yet another variant of the blas, mkl, et al. dance in stock for me, that I was unaware of, which I cannot resolve, and on which I would appreciate your help. I.e. usually, upon conda update --all and once in a while my blas, x.y, mkl, conda-forge got upgraded to some version x1.y1 higher then the previous. But since approximately a month ago my blas got downgraded to version 1.0

(py) ~>conda list | grep mkl
blas                      1.0                         mkl    conda-forge

and ever since then it remains stuck there, even if at least at the time of writing

(py) ~>conda search -f blas | grep mkl
Loading channels: done
# Name                       Version           Build  Channel             
blas                            2.21             mkl  conda-forge         

Is there a way to find out why, which package, or whatever keeps me at 1.0 even if at least 2.21 is available?

Answer 1

Use mamba repoquery

One of the extra commands that Mamba adds over Conda is the repoquery tool. Namely, the whoneeds subcommand will identify packages that has a blas requirement listed in the metadata.

Example

Here is an example from an older environment I have sitting around, that happens to have blas=1.0=mkl installed.

## activate the environment
$ mamba activate umap

## query for depending packages
(umap) $ mamba repoquery whoneeds blas
# ...
Executing the query blas

 Name         Version Build          Depends      Channel  
────────────────────────────────────────────────────────────
 scikit-learn 0.20.3  py37h27c97d8_0 blas 1.0 mkl pkgs/main
 mkl_random   1.0.2   py37h27c97d8_0 blas 1.0 mkl pkgs/main
 numpy        1.16.2  py37hacdab7b_0 blas 1.0 mkl pkgs/main
 numpy-base   1.16.2  py37h6575580_0 blas 1.0 mkl pkgs/main
 mkl_fft      1.0.10  py37h5e564d8_0 blas 1.0 mkl pkgs/main
 scipy        1.2.1   py37h1410ff5_0 blas 1.0 mkl pkgs/main

However, to determine some chain of blame, we probably need to look at the explicit specifications in the environment. For this environment, it is kind of trivial:

## the `--from-history` flag will show only explicit specifications
$ mamba env export -n umap --from-history
name: umap
channels:
  - defaults
dependencies:
  - umap-learn

That is, there is only one specified package in this environment, and it wasn't in the list. It might be additionally helpful to view the depending packages as a tree:

(umap) $ mamba repoquery whoneeds --tree blas
# ...
Executing the query blas

blas[1.0]
  ├─ scikit-learn[0.20.3]
  │  └─ umap-learn[0.3.8]
  ├─ mkl_random[1.0.2]
  │  └─ numpy[1.16.2]
  │     ├─ scikit-learn already visited
  │     ├─ numba[0.43.1]
  │     │  └─ umap-learn already visited
  │     ├─ mkl_fft[1.0.10]
  │     ├─ scipy[1.2.1]
  │     │  ├─ scikit-learn already visited
  │     │  └─ umap-learn already visited
  │     └─ umap-learn already visited
  ├─ numpy already visited
  ├─ numpy-base[1.16.2]
  │  ├─ mkl_random already visited
  │  └─ numpy already visited
  ├─ mkl_fft already visited
  └─ scipy already visited

Here, we see how umap-learn is connected to the chain of packages that are directly specifying blas=1.0. In this case, I probably could just run mamba update umap-learn and it would move on. I.e., it's not stuck like in OP.

Dry-run newer version

A less forensic approach would be to try letting Conda/Mamba blame a package. This is not always reliable, but sometimes it works. Conda is particularly bad at this, so I'd try Mamba:

## try installing a newer blas, but use `-d` for dry-run
mamba install -n py -d 'blas >1'

In the best case, it will report a package that is conflicting with this request.