How can the channel order from a yaml conda environment be made persistent?

Question

I am creating a conda environment from myenv.yml. The contents include

channels:
  - mychan
  - defaults
  - conda-forge
dependencies:
  - matplotlib
  - pandas
  - myweirdpy
  - exoticcondaforgelib

The channel order is important, but I cant tell from the scant docs I've found whether conda env create with a channels section implies preferred channel order and strict channel order isn't an option on the command. It seems a lot of people use conda create to create an empty environment, then use conda config to enforce the strict order, then use conda env update to catch the yaml part. There is an example in one of the answers at Set the channel_priority in Conda environment.yaml. But the behavior is still not clear to me. For instance, this answer has channel priorities in the .condarc and in the yaml. How is this resolved? Would it do the right thing if I set channel priority strict using conda-config?

Ideally I also want the order of the dependencies respected if I update one library or install something new with dependencies, so I guess I don't mind setting up .condarc for posterity. The ideal way for me to make this simple for users would be if there were a way to set channels in yaml and have them be strictly respected and used to generate an environment-specific .condarc.

Answer 1

There's not a simple transparent mechanism to accomplish this. An environment-local .condarc file is a good strategy and likely the simplest to follow for users. Otherwise, you would have them run conda config --env commands with the environment activated which effectively just creates the same .condarc.

An alternative hacky approach might be to create a custom package that sets such configuration options, but that has shortcomings and some might regard it as taboo. That is, a post-link script could potentially manipulate the environment's local .condarc to conform your desired settings. However, that wouldn't prevent users from changing them manually, and therefore even having the custom package installed couldn't guarantee that the environment is in the state that package was intended to signify.