Setup-miniconda: Setup-miniforge

The changes would be:

• Changing the default Miniconda installer so it points to the Miniforge releases instead
• Hardcoding conda-forge+defaults as the default channel configuration
• Anything else?

If that's the case, I guess it's easy to maintain with a little script, yes. I for one would prefer Miniforge to Miniconda as well.

Another option would be to deprecate installer-url and miniconda-version and merge them in a single key like conda-distribution or something like that. This key would allow _magic keywords_ like "miniconda", "miniforge", or "anaconda", that would default to the latest URL for those installers, but would also accept URLs directly (for example, if users want to use their custom constructor-derived installers).

Hi @jaimergp

So from your list:

Changing the default Miniconda installer so it points to the Miniforge releases instead

Sure, but I think we can actually just remove the defult defaults (or update them) when users are not installing a new miniconda/miniforge since. I usually just used the bundled one (which tends to be faster even with updating conda).

Hardcoding conda-forge+defaults as the default channel configuration

Yep we can do that

Anything else?

Hmmm make sure the scripts replaces the right things on readmes and maybe just maintain a V1, V2 (major) versions so we do not need to recreate tags.

I feel like not breaking back-compat is important, as we have seen. I'd say the v2 line needs to stay with a miniconda default, while v3 would be fine to change the defaults, if not the name. Either way, i'd say it's totally fine to just have prefixes, e.g. miniforge-* and miniconda-*. Further, miniforge use a slightly different URL scheme (e.g. pypy) than miniconda, so we'd need to handle all their spec bits to make it feel smooth.

The work started on #98 pointed out that we need to beef up the "get me an installer" game, perhaps move it to another folder with a file per strategy, e.g.

download/
  base.ts
  file.ts
  custom.ts
  miniforge.ts
  miniconda.ts

as our architectures, etc. will become disjoint.

To _that_ end, we probably also want a higher-level, well-typed object of the parsed actions inputs so that we're not doing as many string things... the giant list of params is getting tiresome, and can only get worse. Part of me wants to chuck it all, and do the d.ts -> JSON schema thing, but we wouldn't get (useful) line numbers out, so some of the value would be reduced.

Thanks for the input @bollwyvl

The work started on #98 pointed out that we need to beef up the "get me an installer" game, perhaps move it to another folder with a file per strategy, e.g.

I like this, definitely something to do!

After #126 lands, this could definitely move forward. The work would be:

• decide on an action.yml scheme, e.g. miniforge-version, etc.
• maybe add some new checks to input.ts,
  
  
  
  • e.g. only one of miniforge-version and miniconda-version may be provided
  
  
• a new file download-miniforge.ts
  
  
  
  • (initially) a copy-pasta job of download-miniconda.ts
  
  
  • no doubt there are ways to reuse code between the two files, though for example, they have different architectures, etc.
  
  
• add to providers in installer/index.ts
  
  
  
  • the ordering is still quite explicit, so it doesn't _really_ matter where it goes
  
  
• test

Once nice thing: it's refreshingly simple to get the latest 30 releases of miniforge:

https://api.github.com/repos/conda-forge/miniforge/releases

without having to do URL scraping. Hooray!

I think we'll also need another key, so e.g.:

use:
  miniforge-version: *
  miniforge-flavor: Mambaforge-pypy3  # `Miniforge3` default 

Instead of flavor we could have variant or build or even construct.

Here's a WIP for the above (needs docs, etc):

https://github.com/bollwyvl/setup-miniconda/pull/2

This starts to address some of the issues on using mamba earlier/more... as if you're installing Mambaforge, i'd imagine you'd want to _use_ mamba, no? Yeah, well, JOKE'S ON YOU, it doesn't support (or transparently delegate) a number of things we use like init. So condaCommand has to take that into account when selecting the proper command to use, and means you gotta have conda around.

The speed difference looks negligible for our test cases, but it's probably still worth pursuing... and I dunno how we'll handle the missing functionality for micromamba...

PR up (with more tests and docs): https://github.com/conda-incubator/setup-miniconda/pull/133