Conda environment.yml exports lack explicit build-string pinning for cross-platform reproducibility

Short answer

No — a single shared environment.yml should not embed full build strings, and Conda offers no solver flag to force build-string matching when they're absent. The version-only export is the intended portable format. If you need build-level (or bit-for-bit) reproducibility across Linux, macOS, and Windows, the supported path is per-platform lock files (e.g., conda-lock) or containers — not a build-pinned YAML.

Why build strings can't live in one shared file

Build strings like py39h123456_1 encode the Python ABI, compiler toolchain, and feature toggles for one specific platform. A build published for linux-64 simply does not exist for osx-arm64 or win-64. If you pin exact builds for every package in one YAML, conda env create will fail with unsatisfiable-spec errors on every OS except the one you exported from. There is no conditional syntax in environment.yml that selects different build strings per platform.

Answers to your three questions

1. Documented strategy without per-platform lock files? Not within Conda itself. Conda's model is functional equivalence: the solver picks a dependency-compatible build for the target platform at install time. Tools like conda-lock exist precisely because Conda's native export doesn't address this — and they work by generating one lock file per platform.
2. Solver flags for strict build matching? None. When build strings are omitted, the solver treats them as free variables and optimizes for dependency satisfaction and channel priority, not for matching a build seen on another machine. You can only pin a build by writing it into the spec (numpy=1.26=py39h123456_1), which reintroduces the portability problem.
3. Recommended team workflow? Keep a minimal hand-written environment.yml (or --from-history export) as the source of truth, then generate per-platform lock files in CI and commit them. Developers and CI runners install from the lock file matching their OS.

Practical workflow

# Generate locks for all target platforms
conda-lock -f environment.yml \
  -p linux-64 -p osx-64 -p osx-arm64 -p win-64

# Install deterministically on any runner
conda-lock install -n myenv conda-lock-linux-64.yml

For the strictest binary identity across heterogeneous machines, containerize: build one Linux image from the linux-64 lock and run it everywhere. This sidesteps the fact that macOS and Windows builds are different binaries by definition.

One caveat worth checking

Even with identical versions, different builds can select different BLAS backends or SIMD paths, producing numerically different (though functionally equivalent) results. If your concern is numerical reproducibility rather than byte identity, verify which BLAS/LAPACK variant each platform resolves:

conda list --explicit | grep -E 'blas|lapack|mkl|openblas'
python -c "import numpy; numpy.show_config()"

Pinning the BLAS metapackage (e.g., libblas=*=*openblas) in the base YAML is a portable way to align that layer across OSes without pinning full build strings.

Uncertainty

This reflects Conda's long-standing solver and export behavior; exact conda-lock CLI flags and any newer Conda lock-file features should be verified against your installed versions (conda --version, conda-lock --version) before rollout.