Introduction

Installing one exact package version in Anaconda is straightforward, but reproducibility depends on more than a single conda install command. Channel choice, Python version, build compatibility, and environment isolation all affect the final solve. The safest workflow is to treat version-pinned installs as environment-level changes, not ad hoc fixes in base.

Basic Syntax for Version-Pinned Installs

Conda uses package=version syntax for a specific release.

conda install numpy=1.26.4

You can pin more than one package at the same time:

conda install python=3.11 pandas=2.2.2 scikit-learn=1.4.2

Conda will try to find one dependency graph that satisfies every requested version. If the combination is impossible, the solver reports conflicts instead of partially installing a broken set.

Prefer a Dedicated Environment

Pinning versions inside base usually causes long-term drift. Create a project-specific environment instead.

conda create -n analysis-env python=3.11 -y
conda activate analysis-env
conda install numpy=1.26.4 pandas=2.2.2

This isolates dependency decisions from unrelated work. It also makes cleanup easy when you need to rebuild from scratch.

Check Available Versions Before Installing

Do not guess which versions exist in your configured channels. Search first.

conda search numpy

If your team uses a specific channel, search there explicitly:

conda search -c conda-forge numpy

This matters because the same package version can have different builds, dependency constraints, and availability depending on channel.

Channel Selection Changes the Result

Conda solving is heavily influenced by channel priority. Mixing defaults, conda-forge, and project-specific channels without a policy is a common source of inconsistent environments.

A clean pattern is to choose one main channel stack per environment:

conda create -n ds-env -c conda-forge python=3.10 numpy=1.24.4 scipy=1.10.1

If you want deterministic behavior across teammates and CI, keep channel configuration explicit in environment files rather than relying on local machine defaults.

Install an Exact Build When Needed

Sometimes version alone is not enough. Binary compatibility problems can require an exact build string.

First inspect available builds:

conda search "numpy=1.26.4"

Then install the full spec:

conda install "numpy=1.26.4=py311h64a7726_0"

This is useful when matching a CI image or reproducing a bug that depends on compiled binary variants.

Export and Recreate Environments

Once the environment solves correctly, export it so other machines can recreate the same stack.

conda env export -n analysis-env > environment.yml

Recreate elsewhere:

conda env create -f environment.yml

For example, an environment file may look like this:

1name: analysis-env
2channels:
3  - conda-forge
4dependencies:
5  - python=3.11
6  - numpy=1.26.4
7  - pandas=2.2.2

Committing this file to the repository is usually more reliable than sharing commands in chat or wiki pages.

Troubleshooting Unsatisfiable Specs

When conda says your request cannot be solved, reduce the problem size and verify assumptions.

Useful sequence:

1. Pin Python version explicitly.
2. Ask for fewer packages at once.
3. Use one primary channel.
4. Check whether an older package build supports your Python version.
5. Try the same solve in a fresh environment.

You can also use mamba if your workflow allows it, because it often provides faster and clearer conflict resolution.

mamba create -n analysis-env -c conda-forge python=3.11 numpy=1.26.4

Verify the Installed Result

Do not stop at solver success. Verify from both conda metadata and the runtime interpreter.

conda list numpy
python -c "import numpy as np; print(np.__version__)"

This catches common mistakes such as installing into one environment while running code from another.

Common Pitfalls

• Installing pinned packages directly into base. Fix: create one environment per project or per compatibility target.
• Mixing channels without understanding solver impact. Fix: keep channel policy explicit and consistent.
• Forgetting that Python version constrains package availability. Fix: pin Python along with critical packages.
• Sharing only a one-line install command with teammates. Fix: export environment.yml after the solve is stable.
• Assuming solver output is harmless. Fix: review planned upgrades and downgrades before confirming.

Summary

• Use conda install package=version to request a specific release.
• Create isolated environments instead of modifying base.
• Check versions and channels before solving.
• Pin Python when compatibility matters.
• Export the final environment so the result is reproducible.