Which build string configurations in environment.yml lock binary reproducibility across platforms?
0 reputation · 20 May 2025, 09:34 UTC
0 reputation · 20 May 2025, 09:34 UTC
To determine whether explicitly pinning build strings in an environment.yml file guarantees that the same binary artifacts are installed on Windows, macOS, and Linux, thereby yielding identical runtime behavior.
While the file can list exact package names, versions, and optional build strings, conda’s solver may still choose different binaries if the build string is omitted or if channel priorities shift. Additionally, newer conda releases can alter dependency resolution, potentially leading to divergent package sets even with identical environment.yml content.
package=1.2.3=py39h1234567) must be included to lock the binary across all supported operating systems?environment.yml is processed by conda 4.10 versus conda 4.12 on the same hardware?35275 reputation · 20 May 2025, 15:11 UTC
A build string pin (e.g., package=1.2.3=h1234567_0) selects one exact package build from a specific channel for the platform on which the solve runs. This is the strongest reproducibility mechanism that environment.yml can express.
Because build hashes are platform‑specific, the same string rarely exists for linux‑64, osx‑64, osx‑arm64 and win‑64. Pinning a build string in a shared environment.yml therefore locks the binary only for the OS where that hash is available; on other platforms conda will either fail to find the package or fall back to a different build, breaking binary reproducibility.
channel_priority: strict (or equivalent) in environment.yml or .condarc so that identical version+build names always come from the same channel.python=3.11.4=h1234567_0). Remember these pins are valid only for the platform you are solving on.conda-lock or run conda env export --no-builds on each target OS and commit those lock files to version control.conda-lock install --conda conda-lock.yml).conda list --explicit on two machines of the same OS and comparing the output; the lists should match exactly.If you are unable to generate per‑platform lock files, the only way to approximate reproducibility with a shared environment.yml is to:
To decide which approach fits your workflow, please confirm: Are you able to generate per‑platform lock files using conda-lock or conda env export for each target operating system? If the answer is no, the recommendation shifts to version‑only pinning with an immutable channel and acceptance of possible binary variance.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 20 May 2025, 19:54 UTC
When a package is declared noarch: python (or noarch: generic) its build string contains no compiled extensions, so pinning the version alone—e.g., package=1.2.3—guarantees identical runtime behavior on Windows, macOS, and Linux. For packages that do contain compiled code, the build hash encodes the platform‑specific toolchain; therefore the same literal string like package=1.2.3=h1234567_0 exists only for the OS on which it was built. To achieve cross‑platform locking you must either restrict to noarch packages or generate per‑platform lock files (via conda-lock or conda env export) and install from the appropriate lock file.