Remove defaults channel on input channel: nodefaults

[liamhuber]

Changes conda setup to run conda config --remove channels defaults when nodefaults is found in the channels input instead of adding the - nodefaults channel. I.e.

- uses: conda-incubator/setup-miniconda
      with:
        channels: conda-forge,nodefaults
        channel-priority: strict

Will correctly give

channels:
- conda-forge
dependencies:
...

Instead of

channels:
- conda-forge
- nodefaults
dependencies:
...

Here is a log of the modified version in action.

Closes #207

[liamhuber]

Example 6 during Adding tools to 'base' env...:

  Removing channel defaults
  /home/runner/miniconda3/condabin/conda config --remove channels defaults
  Warning: 
  CondaKeyError: 'channels': 'defaults' is not in the 'channels' key of the config file
  
  
  
  CondaKeyError: 'channels': 'defaults' is not in the 'channels' key of the config file

The patch is working as-intendend and in Applying initial configuration... we correctly get:

  Removing channel defaults
  /home/runner/miniconda3/condabin/conda config --remove channels defaults

But then there's something in the Ex6 config that differs from my simple test case that causes it to double-dip for defaults.

[liamhuber]

Ok, got it: the setup runs applyCondaConfiguration a second time. So it's just my own new if-clause come to bite me.

[liamhuber]

Ok, the log shows the nodefaults option correctly purging the defaults channel. After that, defaults gets added back in because it's included explicitly in etc/example-environment.yml. This is a bit odd when nodefaults gets passed to as an action arg, but it is internally consistent with the existing behaviour where the provided env file is the highest authority, so it seems reasonable to me. I'm content with this and feel this is ready for review.

[liamhuber]

@conda-incubator/setup-miniconda tests are passing, just waiting on a review.

[jaimergp]

Suggested change

	core.info("Removing channel defaults");
	if (channel === "nodefaults") {
	if (channel === "nodefaults") {
	core.info("Removing channel defaults");

[jaimergp]

Just a tiny comment with the logging statements. LGTM otherwise.

[jezdez]

I don't agree we should further the "nodefaults" workaround in setup-miniconda, it's a bad API since it's not an actual channel and tends to increase the risk of a messy channel management

[jezdez]

I think it might be enough to simply offer "override_channels" as a config option, which requires specifying a channel but doesn't hard-code the "nodefaults" workaround.

[jezdez]

A more explicit and future-proof solution is relying on the --override-channels CLI option since nodefaults is a pretty bad workaround within conda. That way, running conda config --remove channels defaults isn't needed here.

[liamhuber]

Just a tiny comment with the logging statements. LGTM otherwise.

@jaimergp, nice catch! Committed 🚀

I don't agree we should further the "nodefaults" workaround in setup-miniconda, it's a bad API since it's not an actual channel and tends to increase the risk of a messy channel management...

@jezdez, the current situation is one "bad" API and a second API that silently deviates from the first API in an unproductive way (i.e. a channel named "nodefaults" is literally added to the channels list). Regardless of whether the conda API is good or bad, I would strongly recommend conda-incubator/setup-miniconda favour consistency over goodness where the two APIs use the same terminology.

I definitely like your suggested --override-channels solution, but I see it as a "yes, and" approach, and I'm afraid you'll need to identify a different volunteer for its implementation.

[liamhuber]

Nice, even better, if conda/conda#14227 is merged I think we can even simply close this PR?

[jaimergp]

Yep, timing will work this time. The only other workaround right now is to explicitly pass a condarc file correctly populated to the condarc-file input.

[liamhuber]

Yep, timing will work this time. The only other workaround right now is to explicitly pass a condarc file correctly populated to the condarc-file input.

Haha, yep, did exactly that downstream a couple weeks ago! pyiron/actions#129