The --no-builds flag removes platform-specific build strings from the conda environment export, making the resulting YAML file usable across different operating systems while still pinning exact package versions.

What Are Build Strings?

When conda installs a package, it records the exact build — including platform, compiler version, and build number — in a hash string like py311h64a7726_0. This build string is platform-specific. An environment exported with default conda env export includes these strings, making the YAML fail when used on a different OS because those specific builds may not exist for the new platform.

Using –no-builds

conda env export --no-builds > environment.yml

This exports package names and version numbers only — without build strings. The resulting file works on Mac, Linux, and Windows because conda resolves the appropriate build for the target platform at install time.

Comparison: Default vs –no-builds vs –from-history

Default (conda env export): exact versions + build strings. Most reproducible, least portable. Use for same-platform deployment. –no-builds: exact versions, no build strings. More portable, still version-pinned. Use for cross-platform sharing with pinned versions. –from-history: only explicitly installed packages, no dependencies, no build strings. Most portable, least pinned. Use when you want the environment to always resolve the latest compatible versions.

Frequently Asked Questions

When should I use –no-builds?

Use --no-builds when sharing an environment between developers on different operating systems (Mac + Linux + Windows), when setting up CI/CD pipelines that run on Linux but development happens on Mac, or when you want version-pinned reproducibility without platform lock-in.