Fix: conda Not Working — Solver Hangs, Channel Conflicts, and Environment Activation

The Error

You install a package and conda hangs forever on “Solving environment”:

$ conda install scikit-learn
Collecting package metadata (current_repodata.json): done
Solving environment: |
# Spins for 30+ minutes, then often fails

Or channel mixing produces conflicts:

UnsatisfiableError: The following specifications were found to be incompatible
with the existing python installation:
  - numpy[version='>=1.24'] from conda-forge
  - tensorflow from defaults

Or conda activate doesn’t work in a fresh shell:

$ conda activate myenv
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.

Or SSL errors when downloading packages:

CondaSSLError: OpenSSL appears to be unavailable on this machine.
OpenSSL is required to download and install packages.

Or pip and conda mix badly:

conda install numpy   # Installs numpy via conda
pip install pandas    # Installs pandas via pip, which installs a different numpy
# Now you have two numpy versions; imports may resolve to either

conda is the dominant Python package manager in scientific computing and ML — handles non-Python dependencies (CUDA, MKL, OpenCV’s C libs) that pip can’t. But conda’s classic SAT solver scales poorly with environment size, channel mixing creates subtle dependency conflicts, and the shell integration requires explicit setup. This guide covers each.

Why This Happens

conda’s classic dependency solver explores the package version space exhaustively. For environments with hundreds of packages from multiple channels, this can take hours or never finish. The modern libmamba solver (now the default since conda 23.10) is 10-100x faster and is what you should use.

conda-forge and defaults (Anaconda’s curated set) sometimes have incompatible builds of the same package — different compiler toolchains, different ABI versions. Mixing them per environment is supported but produces conflicts more often than sticking to one channel.

Fix 1: Use the libmamba Solver

The classic solver is the #1 reason “conda is slow.” Switch to libmamba:

# Check current solver
conda config --show solver
# solver: classic   (or libmamba if already switched)

# Install libmamba solver
conda install -n base conda-libmamba-solver

# Set as default
conda config --set solver libmamba

# Or use per-command
conda install --solver=libmamba scikit-learn

libmamba is the same Rust-backed solver as mamba (the standalone faster conda) but integrated into the conda CLI. Since conda 23.10, libmamba is the default in new installations.

Or switch entirely to mamba:

# Install mamba via miniforge (recommended)
# Download from https://github.com/conda-forge/miniforge
bash Miniforge3-Linux-x86_64.sh

# Or via conda
conda install -n base -c conda-forge mamba

# Now use mamba as drop-in replacement
mamba install scikit-learn
mamba create -n ml python=3.12 pytorch
mamba env update -f environment.yml

mamba vs libmamba solver:

• mamba — Standalone binary, faster CLI startup, all-Rust
• libmamba solver — Same resolver, but used via conda CLI
• micromamba — Stripped-down conda alternative, ~10MB, no Python runtime needed

Common Mistake: Sticking with the classic solver after conda 23.10. The classic solver still ships as an option, but it’s vastly slower and prone to giving up on complex environments. Always check that libmamba is active (conda config --show solver).

Fix 2: Channel Strategy — conda-forge vs defaults

conda has two main channel sources:

• defaults — Anaconda’s curated set (only ~7000 packages, but tested as a coherent group)
• conda-forge — Community-maintained (>20,000 packages, broader coverage)

Conflicts arise when you mix them. Best practice: pick one and stick to it per environment.

Use conda-forge exclusively:

# Per-command
conda install -c conda-forge scikit-learn

# Per-environment (set channel priority)
conda config --env --add channels conda-forge
conda config --env --set channel_priority strict

# Globally
conda config --add channels conda-forge
conda config --set channel_priority strict

channel_priority strict means conda prefers packages from higher-priority channels. With conda-forge as the highest, conda never pulls from defaults unless a package exists only there.

Use miniforge instead of Anaconda/Miniconda:

Miniforge is a minimal conda installer that defaults to conda-forge. No defaults channel by default — no channel mixing issues.

# Linux
wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh
bash Miniforge3-Linux-x86_64.sh

# macOS
brew install miniforge

# Windows
# Download installer from miniforge releases page

Pro Tip: For ML/data science work, use miniforge over Anaconda. The conda-forge ecosystem has more packages, more recent versions, and avoids the licensing changes Anaconda introduced (Anaconda’s terms now restrict commercial use in larger orgs without a paid license; conda-forge has no such restrictions).

Fix 3: Shell Activation Setup

$ conda activate myenv
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.

conda needs shell hooks to activate environments — these aren’t installed automatically in all setups.

Initialize for your shell:

# Detect your shell
echo $SHELL

# Run init for the right shell
conda init bash        # bash
conda init zsh         # zsh
conda init fish        # fish
conda init powershell  # PowerShell
conda init cmd.exe     # Windows cmd

Restart your shell after conda init. The changes write to your shell’s RC file (~/.bashrc, ~/.zshrc, etc.) and take effect on next login.

What conda init does — adds a block like this to your RC file:

# >>> conda initialize >>>
__conda_setup="$('/path/to/miniforge3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/path/to/miniforge3/etc/profile.d/conda.sh" ]; then
        . "/path/to/miniforge3/etc/profile.d/conda.sh"
    else
        export PATH="/path/to/miniforge3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

Manually source for one-off use without modifying RC files:

source /path/to/miniforge3/etc/profile.d/conda.sh
conda activate myenv

Fix 4: Environment YAML Files

The canonical way to share environments:

# environment.yml
name: my-ml-env
channels:
  - conda-forge
dependencies:
  - python=3.12
  - numpy>=1.26
  - pandas>=2.2
  - scikit-learn>=1.5
  - jupyter
  - matplotlib
  - pip
  - pip:                     # pip-only packages
      - mlflow>=2.10
      - openai>=1.30

Create / update:

conda env create -f environment.yml
conda env update -f environment.yml --prune   # Remove deps no longer listed

# Activate
conda activate my-ml-env

Export current environment:

# Full export (includes build hashes — least portable)
conda env export > environment.yml

# History-only (recommended — only lists packages YOU installed)
conda env export --from-history > environment.yml

# Cross-platform (no build strings)
conda env export --no-builds > environment.yml

Common Mistake: Committing the full conda env export output. The build hashes (numpy=1.26=py312h...) are platform-specific — your environment.yml works on your Linux laptop but fails on the team’s Mac. Always use --from-history to capture only your explicit installs.

Lock files for reproducible builds:

# Install conda-lock
conda install -c conda-forge conda-lock

# Generate lock file (resolves once, locks exact versions per platform)
conda-lock -f environment.yml -p linux-64 -p osx-arm64 -p win-64

# Install from lock
conda-lock install --name my-env conda-lock.yml

conda-lock is the “lock file” equivalent for conda — like package-lock.json for npm. Pin exact builds across platforms for reproducible installs.

Fix 5: pip and conda Coexistence

Mixing pip and conda in the same env is supported but risky. Best practices:

# Activate conda env FIRST
conda activate myenv

# Then use pip — installs go into the env's site-packages
pip install some-package

# Verify pip is the right one
which pip
# /path/to/miniforge3/envs/myenv/bin/pip

Common Mistake: Running pip install without activating the conda env. The pip used is your system pip, installing globally — and the package isn’t in the conda env at all. Always activate first, or use python -m pip install ... to guarantee the right pip.

Order matters in environment.yml — conda installs first, then pip handles its section:

dependencies:
  - python=3.12
  - numpy           # Installed by conda
  - pip             # Required to use the pip: section
  - pip:
      - mlflow      # Installed by pip after conda finishes

Avoid pip overwriting conda-installed packages:

# WRONG — pip might pull a different numpy, breaking conda's numpy + scipy + scikit-learn coherence
pip install numpy==1.26.4

# CORRECT — let conda install the scientific stack, use pip only for pip-only packages
conda install numpy scipy scikit-learn
pip install mlflow wandb   # Things conda doesn't have

Pro Tip: As a rule, install everything you can via conda, fall back to pip only for packages conda-forge doesn’t have. This keeps the scientific Python stack (numpy, scipy, scikit-learn, pytorch) coherent — they share binary dependencies (MKL, OpenBLAS, CUDA libs) that pip can’t manage as well as conda.

Fix 6: CUDA and GPU Packages

# PyTorch with CUDA 12.1
conda install -c pytorch -c nvidia pytorch pytorch-cuda=12.1

# Or via conda-forge (also good)
conda install -c conda-forge pytorch pytorch-cuda=12.1 cudatoolkit

# TensorFlow with GPU
conda install -c conda-forge tensorflow-gpu

Verify GPU support:

conda activate myenv
python -c "import torch; print(torch.cuda.is_available())"
python -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

Common Mistake: Mixing CUDA versions across packages. PyTorch needs CUDA 12.1, but you also installed cudatoolkit=11.8 from another command — they conflict. conda’s solver usually catches this, but manually installing CUDA via pip after conda installed it via conda-forge leads to mismatched versions silently.

For PyTorch-specific CUDA setup issues, see PyTorch not working. For TensorFlow GPU configuration, see TensorFlow not working.

Fix 7: Cleaning Up

conda installations grow over time — cached packages, removed envs leave artifacts:

# Show disk usage
conda info

# Clean caches
conda clean --all                # Removes index cache, unused packages, tarballs
conda clean --tarballs           # Just the downloaded tarballs
conda clean --packages           # Unused packages (not in any env)

# List environments
conda env list

# Remove an environment
conda env remove --name old-env

# Remove all caches and unused packages
conda clean -ay   # -a = all, -y = no confirmation

Reset to a clean state:

# WARNING — destroys all envs and configs
rm -rf ~/miniforge3
# Then reinstall miniforge

A full reinstall is sometimes faster than untangling a broken conda installation. Back up your environment.yml files first.

Fix 8: Channel-Specific Issues

http_proxy for corporate networks:

conda config --set proxy_servers.http http://proxy.company.com:8080
conda config --set proxy_servers.https http://proxy.company.com:8080

Or via env vars (preferred):

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
conda install ...

CondaSSLError — usually a corporate firewall or out-of-date OpenSSL:

# Allow SSL bypass (insecure — only as last resort)
conda config --set ssl_verify false

# Or point to a custom CA bundle
conda config --set ssl_verify /path/to/corporate-ca.pem

Custom channels — internal package mirrors:

conda config --add channels http://internal.example.com/conda-mirror

Token-authenticated channels:

conda config --add channels https://my-org:[email protected]

For pip-specific SSL issues that also affect conda environments, see pip SSL certificate verify failed.

Still Not Working?

conda vs mamba vs uv

• conda — Manages Python + binary deps + non-Python tools (R, Julia, Node). Best for cross-language scientific environments.
• mamba — Drop-in conda replacement, faster.
• uv — Pure Python package manager, blazingly fast. Best when you only need Python. See uv not working.
• pixi — Modern conda-replacement built on conda-forge, faster, lockfile-first.

For scientific Python with CUDA / R / system libs, conda/mamba is the right tool. For pure Python projects, uv is faster and lighter.

Reinstalling a Stuck Environment

# Delete the env
conda env remove -n broken

# Recreate from yaml
conda env create -f environment.yml

# Or copy from backup
conda create --clone source-env -n new-env

Cloning is faster than recreating if the source env is still working.

Debugging Solver Failures

# Verbose mode shows what the solver is trying
conda install -v scikit-learn

# Force solver to suggest alternatives
conda install scikit-learn --strict-channel-priority

# Show what would change without installing
conda install scikit-learn --dry-run

The dry-run output shows the planned changes — useful to verify a complex install before committing.

Integration with Jupyter

conda install -c conda-forge jupyter ipykernel
python -m ipykernel install --user --name=myenv --display-name "Python (myenv)"

# Now select "Python (myenv)" in Jupyter's kernel menu

For Jupyter kernel selection issues, see Jupyter not working.

Use with Docker

FROM mambaorg/micromamba:latest

COPY environment.yml /tmp/env.yml
RUN micromamba install -y -n base -f /tmp/env.yml && \
    micromamba clean --all --yes

ARG MAMBA_DOCKERFILE_ACTIVATE=1
COPY . /app
WORKDIR /app

CMD ["python", "main.py"]

micromamba is preferred over conda inside Docker — smaller image, no Python runtime needed.

Combining with Hatch / PDM for Distribution

If you publish a package, you typically distribute via PyPI (pip) even if you develop with conda. Keep environment.yml for development; use pyproject.toml for distribution. For Hatch-based distribution, see Hatch not working. For PDM, see PDM not working.