Exporting a conda environment to a yaml file won't let me rebuild it on the same machine

I have a working conda environment that I want to share with a colleague who is working on the same computer cluster. I exported my environment to a YAML file but then I cannot recreate the environment using that YAML file again due to incompatible packages. The full error message is:

Could not solve for environment specs.

The following packages are incompatible

• alsa-lib 1.2.6.1** is requested and can be installed;
• click 8.1.3** is installable with the potential options
  • click 8.1.3, which can be installed;
  • click 8.1.3 would require __win , which is missing on the system;
• dask 2022.2.0** is uninstallable because it requires
  • distributed >=2022.2.0,<2022.2.1.0a0 , which requires
    • click >=6.6,<8.1.0 , which conflicts with any installable versions previously reported;
    • openssl !=1.1.1e , which can be installed;
      distributed 2022.2.0** , which cannot be installed (as previously explained);
• gst-plugins-base 1.20.3** is installable with the potential options
  • gst-plugins-base 1.20.3, which can be installed;
  • gst-plugins-base 1.20.3 would require
    • alsa-lib >=1.2.7.2,<1.2.8.0a0 , which conflicts with any installable versions previously reported;
• icu 69.1** is requested and can be installed;
• openssl 3.0.5** is requested and can be installed;
• qt 5.12.9** is uninstallable because there are no viable options
  • qt 5.12.9 would require
    • openssl <3 , which conflicts with any installable versions previously reported;
  • qt 5.12.9 would require
    • icu >=67.1,<68.0a0 , which conflicts with any installable versions previously reported;
  • qt 5.12.9 would require
    • icu >=68.1,<69.0a0 , which conflicts with any installable versions previously reported;
  • qt 5.12.9 would require
    • gst-plugins-base >=1.18.5,<1.19.0a0 but there are no viable options
      • gst-plugins-base 1.18.5 conflicts with any installable versions previously reported;
      • gst-plugins-base 1.18.5 would require
        • alsa-lib >=1.2.3,<1.2.4.0a0 , which conflicts with any installable versions previously reported.

Why is this happening? How can a working conda environment have incompatible packages?

• I start with a working conda environment.
• I try to create the environment on the same system.
• My YAML file has both the default and the conda-forge channel.
• I tried installing the conda environment both from a --no-build YAML file and a full YAML file but both had incompatible packages.

The conda env export function doesn’t capture channels of origin properly for any ad hoc commands that may have used a -c flag when mutating the environment. Rather, it simply captures the current user configuration of channels (including any environment-specific ones in the active environment, which is not necessarily the exported one!). Moreover, solving is context-sensitive to the channel_priority setting. E.g., strict mode can cause packages from channels to be masked. That is, it is entirely feasible to go through a series of ad hoc install commands that switch channel priority in such a way that the final set of packages could not be installed from a single YAML with just one strict channel priority.

Since you are on the same system, there should definitely be a path forward to recreating the exact environment.

First, make sure that channel_priority is “flexible”. Second, have a look through the conda list output for the environment and make sure that all the channels listed there are included in the YAML.

A more strict recreation strategy that can be used when working on the same system is conda list --explicit.

Longer term, one can adopt more reproducible package management practices by always working from a YAML definition from the start. That is, avoid ad hoc mutations of the environment and instead always use conda env {create,update} commands.

A newer solution in this space is conda-lock, which literally presolves environments and includes just the URLs needed for download.