Disappearance of intel conda channel

[Jacob_Williams]

It seems that the intel conda channel is no longer available?

I.e., https://anaconda.org/intel

We used to be able to install the intel compiler runtime libs by using the intel channel in a conda environment.yml file like so:

channels:

  - conda-forge

  - intel

dependencies:

  - intel::fortran_rt=2023.0.0

But it's no longer working. Is this channel gone for good? Was there any announcement about that or what the recommended way forward is?

[SamTygier]

There is some discussion but no solution yet at https://community.intel.com/t5/Intel-Integrated-Performance/Problems-installing-with-conda-HTTP-403-FORBIDDEN/m-p/1611876

[Jacob_Williams]

For future reference: I originally posted this in the Fortran forum: https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler

[Jacob_Williams]

Inferring from this link: 

https://www.intel.com/content/www/us/en/docs/oneapi/installation-guide-linux

[then click installing from package managers, then conda]

It appears that Intel is now self-hosting their conda packages at: 

https://software.repos.intel.com/python/conda/

So, the anaconda/intel channel is no more? It would be nice to get some official word from intel about this. This has broken many workflows seemingly without warning. 

[Trackah123]

Had the same issue, thanks to your repo advice i managed to get it to work like this.

Example packagename "onednn"

conda install conda-forge::onednn -c https://software.repos.intel.com/python/conda/ --override-channels

[The_Hedgehog]

Thanks, that's helpful!

That almost did it for me, but I also needed the following to get rid of issues while using Anaconda Navigator:

conda config --set allow_non_channel_urls True

Found that solution here:

https://stackoverflow.com/questions/78761316/conda-is-using-a-channel-after-i-removed-it 

It's not a 100% clean solution because this seems to tell the system to simply ignore the channel that isn't working but I tried other solutions and couldn't get rid of the issue otherwise. Even after removing the (old) intel channel, the system was still trying to use it for some reason.

[DManowitz]

It seems like the issue you are encountering is the same as this one that I reported.  Is is an issue with the libmamba solver for conda.  You can set the environment variable CONDA_LIBMAMBA_SOLVER_NO_CHANNELS_FROM_INSTALLED=1, at least with conda-libmamba-solver>=23.9.0, and that should fix your issue.  You can also use the classic conda solver or use mamba itself, and you shouldn't see these errors.

[The_Hedgehog]

Thanks for the excellent suggestion!

I tested once again, and first reverted the "set allow_non_channel_urls" change that I mentioned above. After that I set the environment variable CONDA_LIBMAMBA_SOLVER_NO_CHANNELS_FROM_INSTALLED=1, as suggested.

I confirm this indeed solves the issue with Anaconda, it then no longer tries to connect to the (old / non-existing) Intel channel, and can install packages again in a normal fashion.

[DManowitz]

It would be nice to get some more official word of exactly what (and, ideally, why) this happened.  I also notice that the new repo doesn't have many of the older versions of various packages (or any Python 3.8 packages).

[Jacob_Williams]

Oh Wow. I just noticed this too that some of the packages in the old channel are not in the new one.

Intel this is just totally unacceptable. Removing the old packages breaks deployment of anything that requires them. If we can't trust this channel to keep the packages there, we can't use this compiler.

What is the policy for retaining old packages? Are we in a situation where we can't rely on any package to stay there forever?