Tips & tricks¶
Using multiple channels¶
It is quite common to install a package from conda-forge and, when trying to use it, see an error like (OS X example):
ImportError: dlopen(.../site-packages/rpy2/rinterface/_rinterface.so, 2): Library not loaded: @rpath/libicuuc.54.dylib Referenced from: .../site-packages/rpy2/rinterface/_rinterface.so Reason: image not found
That happens because either the correct version of
or any other package in the error,
is not present or the package is missing altogether.
You can confirm this by issuing the command
conda list and searching for the package in question.
Why does that happen?¶
defaults are not 100% compatible.
In the example above it is known that
icu 54.* while
conda-forge relies on
that mismatch can lead to errors when the install environment is mixing packages from multiple channels.
All of conda-forge software pinning can be found at: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml
How to fix it?¶
conda versions (>=4.6) introduced a strict channel priority feature.
conda config --describe channel_priority for more information.
The solution is to add the
conda-forge channel on top of
defaults in your
.condarc file when using
and activate the strict channel priority with:
$ conda config --set channel_priority strict
This will ensure that all the dependencies come from the
conda-forge channel unless they exist only on
Here is how a
.condarc file would look like:
$ cat .condarc channel_priority: strict channels: - conda-forge - defaults
In addition to the channel priority, we recommend always installing your packages inside a new environment instead of the
base environment from anaconda/miniconda.
Using envs make it easier to debug problems with packages and ensure the stability of your root env.
In the past
conda-forge used to vendorize some of
defaults dependencies that were not built in our infrastructure,
like compilers run-times, to avoid the mixing channel problem.
However, with the
strict option, we no longer have to vendorize those (this led to its own set of problems),
instead, we removed everything that is not built in
conda-forge and let
strict pull those from
TL;DR if you are experiencing missing compilers run-times like
that is probably because you removed
just re-add it and activate
strict for a smooth and stable experience when installing packages.
Using External Message Passing Interface (MPI) Libraries¶
On some high-performance computing (HPC) systems, users are expected to use the
MPI binaries that are available on the system as opposed to those built by
These binaries are typically specialized for the system and interface properly with job
schedulers, etc. However, this practice creates issues for
conda-forge users. When you install
a package from
conda-forge that relies on MPI,
conda will install the MPI binaries
conda-forge and the package will link to those binaries. This setup often either
does not work at all or functions in unexpected ways on HPC systems.
To solve these issues,
conda-forge has created special dummy builds of the
that are simply shell packages with no contents. These packages allow the
conda solver to produce
correct environments while avoiding installing MPI binaries from
conda-forge. You can install the
dummy package with the following command
$ conda install mpich=3.3.*=external_*
As long as you have the local copies of the
mpich library in your linking paths and
the local version matches the
conda version up to the minor version number (e.g.,
3.3.2 but not
3.4.1), then this procedure should work. At runtime, the
package that depends on MPI should find the local copy of
mpich and link to it.
mpich has a high degree of ABI compatibility, making this procedure possible.
We have not currently implemented this procedure with
openmpi, but can do so at a later date
as ABI compatibility allows.