openmp vs llvm-openmp

[kirelagin]

I am trying to install pytorch (cpu) and mlpack into the same environment, but this command fails:

$ mamba create -n tst 'python=3.9.*' 'pytorch=*=cpu*' 'mlpack'
<...>
Looking for: ['python=3.9', 'pytorch=[build=cpu*]', 'mlpack']

conda-forge/linux-64                                        Using cache
conda-forge/noarch                                          Using cache
Encountered problems while solving:
  - package pytorch-1.10.0-cpu_py39hc5866cc_0 requires python_abi 3.9.* *_cp39, but none of the providers can be installed

The root cause, as far as I understand, is that pytorch depends on llvm-openmp (via mkl) and mlpack depends on openmp (via ensmallen).

I can install them individually:

$ mamba create -n tst 'python=3.9.*' 'pytorch=*=cpu*'

pulls in llvm-openmp-14.0.4, while:

$ mamba create -n tst 'python=3.9.*' 'mlpack'

pulls in openmp-8.0.1 (the latest available version, three years old).

llvm-openmp has a constraint that if openmp is installed it has to have the same version and mkl requires llvm-openmp >= 9.0.1, which does not have a corresponding openmp version.

My current understanding is that openmp and llvm-openmp are the same package, with the former being its old name which is no longer updated. Unfortunately, I could not find any documentation / history / discussions on this matter.

Am I right? If yes, it would be great to have some easily googleable documentation for this.

Wouldn’t it be better to keep publishing openmp as a proxy for llvm-openmp for backwards compatibility? There are still plenty of packages depending on it.

In any case, I would be grateful for any suggestions on how to work around this problem, given that conda-forge/ensmallen-feedstock does not seem to be actively maintained. I assume, ensmallen should work just fine with the newer versions of llvm-openmp if I find a way to trick conda/mamba into ignoring this dependency.

[isuruf]

Wouldn’t it be better to keep publishing openmp as a proxy for llvm-openmp for backwards compatibility? There are still plenty of packages depending on it.

We published for version 8 for backwards compatibility and removed it later on. You can take over maintainership of ensmallen-feedstock and fix the dependency.

[jakirkham]

Anything else needed here? Or should we close?

[h-vetinari]

We're still not there yet. llvm-openmp isn't used universally yet (for openblas, it got stuck on the flang migration), and pytorch etc. still require the intel-openmp AFAIR.