Conda install some-package hangs with (Solving environment: failed)

Question

I have tried multiple ways but can't conda install packages (in my case, geopandas). I tried geopandas install guide, but get output that the solver runs forever. I tried without creating an environment, after creating a new environment, using defaults channel and using conda-forge channel. None worked.

$ conda create -n top 
$ conda activate top
$ conda config --env --add channels conda-forge
$ conda config --env --set channel_priority strict
$ conda install python=3 geopandas

Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: \ 

I don't want to use pip install because it is preferred to use conda install.

Also I tried installing using Anaconda Navigator following this answer, but the progress bar keeps hanging, saying "solving package specifications".

Solution 1

Favor Specifying Constraints at Creation

Iteratively installing packages is a real choking point for Conda. If you know up front that the env will require certain packages, then specify them at creation:

conda create -n top -c conda-forge -c defaults python=3 geopandas

This solves in seconds for me. If you have many packages, then use a YAML.

Use Mamba

Sometimes ad hoc installations are unavoidable. For tough solves (or just generally), try using mamba, a compiled (fast!) drop-in replacement for conda. Mamba will shine where Conda struggles.

# install mamba
conda install -n base conda-forge::mamba
# use mamba
mamba install -n top geopandas

Solution 2

After trying many advice from Conda's GitHub page, I found out that the issue was not being able to find dependencies for the python version I had installed. Creating new environment help but with one more argument for python version.

conda create -n branch-env python=3.7
conda activate branch-env
conda install geopandas

Solution 3

The conda message "Solving environment: failed with initial frozen solve. Retrying with flexible solve." comes from

Conda install some-package hangs with (Solving environment: failed)

The answer above deserves provides one of the best answers that I have seen anywhere to deal with the time-consuming problem of package incompatibilities and waiting endlessly for conda solver sessions to finish.

The key is to learn in advance what packages you will likely need to use, and then specify those packages UP-FRONT when you create your conda environment, but leave the Python 3.x subversion "floating"). Conda will figure out which sub-version of Python 3.x is the latest and most appropriate to solve the dependencies for all other packages in your target environment.

This approach of determining and specifying your required environment "core" packages up front -- then letting conda work out which Python 3.x version -- avoids the problem of downgrading Python (which frequently does not work).

When your new conda solves and builds your new environment, it can be cloned as a template for future similar work.

Comments

[SadHak]

I am on Mac OS Catalina. Running conda update works fine. I did mdfind anaconda on terminal and noticed I had anaconda installed in 3 places. I had it in /opt , and twice in root dir /anaconda3 and /anaconda. I am thinking of removing it completely and reinstalling if can't figure it out.

[SadHak]

I did try flexible as well but didn't help. I think the problem was python version used to create the env. I created new environments using python=3.6 and python=3.7, and then I could install all the packages I needed without any issue using conda install. I still can't install packages in my root (base) env. I think I will leave root alone.

[smci]

Does mamba ever break the conda environment?

[merv]

@smci in general, or are you specifically asking about base (which Conda itself is known to frequently break)? It might be too soon to simply answer, "No." It does use a different SAT solver (libsolv) at its core, but as long as that is technically correct, there shouldn't be breakage. Breakage due to poorly defined package metadata would equally affect Conda and Mamba. Anecdotally, I have not seen any such reports. If you are particularly concerned, maybe check the Issues, but I don't see anything major.

[smci]

merv: sure, I was just suggesting give a bit of guidance about expectations for mamba replacing the conda solver.

[User 10482]

Specifying constraints at environment creation did it for me. Thanks!

[Rich Lysakowski PhD]

The first part of your answer is the best advice that I have seen anywhere, which is to specify up front the environment packages you will need (with Python 3.x "subversion floating") and let conda figure out which sub-version of Python 3.x is most appropriate to solve the dependencies for all other packages in your target environment. Determine your required "core" packages up front and let conda work out which Python 3.x version avoids the problem of downgrading Python, which is frequently does not work. When conda solves the environment can be cloned as a template for future similar work.