Version 2: Stop writing to `~/.condarc` and remove some options

[jonashaag]

The current interface has a bunch of problems:

• Cannot run provision-with-micromamba twice in some scenarios #102
• Use temporary directory for temporary condarc #97
• Deduplicate keys in temporary condarc #96
• condarc-file keys are overwritten #94
• channels overridden even if empty #112
• Behavior of channels and channel-priority is very confusing:
  • They will be added to ~/.condarc.
  • condarc-options: channels has precedence.
  • It is very hard to implement a channel fallback to conda-forge.
  • We default to channel-priority: strict (also automatically add that to ~/.condarc)

Some of the problems with channels have been inherited from setup-miniconda but I don't think it's worth staying compatible (we're not compatible in other ways anyways).

I don't think we should be using channels in the first place, with one exception. We should be specifying channels in the environment.yml and in a .condarc. You want to be able to install from environment.yml outside of CI anyways. I'm not sure why we set channel_priority: strict but I think this one should also not be CI specific, so set in .condarc. The exception for a valid use case for channels being if you don't have an environment.yml.

My suggestion is as follows:

• Remove the channels option.
• Don't set the channel_priority option and remove the channel-priority option.
• For the special case of environmnent-file: false use channels: [conda-forge]. Other channels are not supported in that case (must create an environment.yml file or use a condarc-file instead).
• Stop writing to ~/.condarc. (Maybe keep the condarc-file -> ~/.condarc copying.)
• Remove the condarc-options option? We could also keep it but make it mutually exclusive with condarc-file.

@wolfv @pavelzw

[jonashaag]

@wolfv I want to start working on this this week, if you have any opionions please share!

[hadim]

Sorry to jump here from nowhere, but I use that action extensively. One use case is releasing a library using only a couple of deps (versus installing everything that is in the repo env.yml file) that all depends on one or more specific channels.

For this need, it's important for us to be able to set extra-specs as well as channels. Take for example the below snippet:

  steps:
    - name: Setup Mamba
      uses: mamba-org/provision-with-micromamba@v14
      with:
        environment-file: false
        environment-name: rever
        cache-downloads: true
        cache-env: true
        channel-priority: strict
        channels: conda-forge
        extra-specs: |
          python
          pip
          conda-smithy
          semver
          git
          rever>=0.5.1

For the special case of environmnent-file: false use channels: [conda-forge]. Other channels are not supported in that case (must create an environment.yml file or use a condarc-file instead).

For this use case, the below proposal would work, but I can imagine some other cases where being able to set channels to something else could be useful.

Would that be possible to keep it but only when environmnent is false and throw an error otherwise?

[jonashaag]

Thanks Hadrien, that's valuable input!

You seem to have some non-trivial environment setup in your GHA workflow, making it hard to run that CI step outside of GHA. I'd argue that one should put code that's not specific to GHA (list of dependencies, list of channels, ...) outside the workflow. Thus rendering those options unnecessary.

For very simple CI steps it might not be worth having that code outside the workflow, but I'd argue your setup is already past that. (Convenient for my argument, I'm defining "simple" = "needs only conda-forge packages with no other options changed" :-))

[jonashaag]

Idea: condarc input as literal string. But could also use cat

[jonashaag]

Please continue discussion of the new version's spec here #114