Channel priority changed in 2.1.0 release

[jrbourbeau]

Distributed's CI specifies the conda channels to use inside a conda environment file where we prefer to use conda-forge where possible and fallback to using defaults when needed.

After the setup-miniconda 2.1.0 release we started observing many more packages being installed from defaults instead of conda-forge (see the links below which compare the packages installed using setup-miniconda=2.0.1 and setup-miniconda=2.1.0). Was this an intentional change that requires users to make changes to our GitHub actions workflow?

• conda list with setup-miniconda=2.0.1
• conda list with setup-miniconda=2.1.0

[jrbourbeau]

Digging a bit deeper into the GitHub actions logs, it looks like during the "Ensuring environment..." step the conda environment file that is produced has the channels in reverse order compared to the original environment file

[bollwyvl]

reversing the order of the channels is no doubt a bug, and may require some investigating of how we use of the yaml channels (they do have to be inverted when setting the config via cli, but certainly should not impact the eventual environment, even if patched).

Quick fix: if you remove the python-version from use (since your envs appear to have it pinned), then the action won't try to apply the patch, which should get you back to the expected behavior, and require fewer conda solves.

Sorry for any inconvenience... we were getting a fair amount of push to get something updated from master to v2... damned if we do, damned if we don't.

[jrbourbeau]

Gotcha, thanks for the additional context!

Unrelated to the new 2.1.0 release, we're moving towards using mamba (which requires explicitly specifying conda channels in the GitHub action step setup), so that should help us circumvent the channel order issue too.

Sorry for any inconvenience... we were getting a fair amount of push to get something updated from master to v2... damned if we do, damned if we don't.

No worries, I appreciate all the work that goes into setup-miniconda -- thanks for making a useful project we can all benefit from

[bollwyvl]

but certainly should not impact the eventual environment, even if patched).

Yup, javascript's reversed edits in-place. We need to do a .slice().reversed() to get a copy.

Unrelated to the new 2.1.0 release, we're moving towards using mamba

Hardly! Go ahead and try out:

use-mamba: true
miniforge-variant: Mamabaforge

And you'll see conda used only for the initial conda-standalone constructor solve (nothing to be done about that at present).

Using an already-on-the-machine mini* is still the fastest, but this approach tries to keep solves to an absolute minimum.

[jrbourbeau]

To be clear, we're still using setup-miniconda but are utilizing the use-mamba, etc. settings you pointed out (the full set of changes we're using as at https://github.com/dask/distributed/pull/4585/files)

[bollwyvl]

Welp, dunno if you've moved on entirely, but 2.1.1 now has fixed and under test. I'll close this, please re-open if any related issues arise!