Conda 'Solving Environment' Stalls and UnsatisfiableError: A Diagnostic Guide

The recognizable condition

You run conda create or conda install, the progress bar reaches Collecting package metadata or Solving environment, and then one of three things happens: it spins for many minutes, it retries channels repeatedly, or it dies with PackagesNotFoundError or a long UnsatisfiableError chain naming packages you never asked for. The useful takeaway: this is almost never a broken conda installation. It is the dependency solver telling you that the channel metadata it can see does not contain a mutually compatible set of builds for your spec. Your job is to find which constraint is unsatisfiable, or why the metadata search space is so large that the solve takes forever.

Cause quick-reference

Check 1: Establish what conda actually sees

Before changing anything, capture the solver's view of the world. In the same terminal where the failure occurs (Anaconda Prompt on Windows, or any shell with conda initialized), run:

conda info
conda config --show

No elevated permissions are needed. Look at four things in the output:

• channels: a long or mixed list (e.g., defaults plus conda-forge plus several niche channels) inflates metadata and invites cross-channel conflicts.
• channel_priority: strict means a package from a lower-priority channel is never used if any version exists in a higher one. This is a common cause of UnsatisfiableError when your spec implicitly needs builds from both families.
• solver: recent conda versions default to the libmamba solver; older installs use the classic solver. They can report the same conflict with different wording.
• platform / subdir: confirm you are solving for the OS you think you are, especially inside containers or on Apple Silicon machines using x86 emulation.

Also check whether the failing command uses an environment file exported on a different operating system. Files from conda env export include exact build strings that often do not exist on other platforms. conda list --explicit output is even more platform-specific.

Check 2: Reproduce minimally with a dry run

Do not keep retrying the full install. Build the smallest failing case with --dry-run, which solves without changing any environment:

conda create --dry-run -n probe python=3.11 somepackage

Start with just Python and one package. If that solves, add your remaining packages one at a time until the conflict appears. The first addition that breaks the solve is your suspect. Then inspect what it actually demands:

conda search --info somepackage -c conda-forge

The depends list in the output shows the exact constraints (for example, python >=3.8,<3.11) that conflict with the rest of your spec. This turns a wall of solver text into a single package pair you can reason about.

Fixes tied to what you find

If the solve is slow but eventually succeeds

• Remove channels you do not need from .condarc; each one multiplies the metadata downloaded and searched.
• Pin Python early (python=3.11) and pin major versions of your heaviest packages. Broad specs force the solver to consider every historical build.

If two packages have mutually exclusive requirements

• Loosen exact build pins (the =py311h1234567_0 style strings) to version-level pins; build hashes are the most fragile constraint.
• Pick one coherent channel family. If most of your stack is on conda-forge, install everything from conda-forge rather than mixing with defaults artifacts.
• Only use channel_priority strict if every package in your spec is published consistently on your chosen channel family; otherwise set it to flexible and keep channels minimal.

If the environment is already damaged

Create a fresh environment instead of repairing base or a long-lived env. Repeated installs, --force operations, and pip-over-conda edits leave partially consistent states that produce confusing solver messages later. Base should stay minimal; real work belongs in named environments.

If metadata looks stale (worked recently, fails now)

Corporate proxies and mirrors can serve partial or outdated repodata that mimics dependency bugs. Clear the local cache and retry:

conda clean --index-cache

This only removes cached metadata and is safe. If you are behind a proxy, also verify the configured channels in conda config --show point where you expect. Switching solver (classic vs. libmamba) is a legitimate controlled experiment for better error text, but do not treat a newer solver as a fix for a genuine metadata conflict.

Verify the fix

1. Re-run the previously failing command with --dry-run first. It should now produce a package plan.
2. Create the environment for real, activate it, and from inside that env only run python --version and import the newly installed packages.
3. Compare conda list --explicit before and after. A clean result changes only the intended packages and keeps channel labels consistent (no surprise mix of pkgs/main and conda-forge builds of the same library).
4. Re-run with higher verbosity (-vv) if you want confirmation that the solver's final explanation names the same package pair you changed.

When to escalate

Escalate to the channel maintainers or your internal mirror administrator when: a minimal two-package dry run still fails after channel and pin cleanup; the identical spec solves on one platform but not another with no documented platform restriction; or the solver output appears internally inconsistent (claiming a constraint that conda search --info does not show). Capture the exact command, full conda info and conda config --show output, the complete solver text, and an environment export. For team automation, save the working spec as an explicit lock-style file (conda list --explicit > spec.txt) and test it in a clean container before distributing.

Note: solver defaults and channel behavior vary by conda version; confirm your version with conda --version and check the current conda documentation before applying this to automated pipelines.