Locking Conda Environments with conda-lock for Reproducible Builds

The problem: drifting dependencies

When you share an environment.yml file, teammates or CI agents may end up with different package versions because channels resolve at install time. This can break tests or produce inconsistent results.

Why conda‑lock helps

conda‑lock reads an environment specification and writes a lockfile that pins every package to an exact version and channel. Committing that lockfile gives you a deterministic build that does not depend on live channel resolution.

Worked example

1. Start with a simple environment.yml:

name: myproj
channels:
  - conda-forge
dependencies:
  - python=3.11
  - numpy
  - pandas

2. Install conda‑lock (e.g., via pip):

pip install conda-lock

3. Generate the lockfile:

conda-lock create -f environment.yml

This creates conda-lock.yml containing entries such as:

 - package: numpy
   version: 1.26.2
   build: h9c3ff2c_0
   channel: conda-forge
 - package: pandas
   version: 2.2.0
   build: h0a44026_0
   channel: conda-forge

4. Commit conda-lock.yml to version control.
5. In CI or a fresh machine, recreate the exact environment:

conda-lock install -f conda-lock.yml

6. Verify that the lockfile matches the installed packages:

conda-lock verify -f conda-lock.yml
conda env export --no-builds > exported.txt
# compare exported.txt with the lockfile list

Trade‑off and limitation

Lockfiles become stale if you change the base environment.yml, add new channels, or upgrade conda itself. Periodically re‑run conda-lock create and review the diff to keep the lockfile up‑to‑date.

Actionable closing

Add the lockfile generation step to your repository’s CI pipeline, gate merges on a successful conda-lock verify, and treat the lockfile as the source of truth for reproducible builds.