What is the difference between miniconda and miniforge?

Question

The miniforge installer is a relatively new, community-led, minimal conda installer that (as it says in its readme) "can be directly compared to Miniconda, with the added feature that conda-forge is the default channel".

It is unclear what is different between miniforge and Miniconda, or what the miniforge use case is.

If miniforge is the same as Miniconda except it just uses the conda-forge channel by default, why create a whole different installer - why not just use miniconda and add conda-forge as the first channel to use in ~/.condarc?

If miniforge is different from Miniconda, what is different about the two?

Comedian

It seems to me like the more relevant difference and the main use case would be to distribute a conda-forge compiled Python by default. As a side effect, it saves you a step of conda config --add channels conda-forge; conda update --all to switch the installed Python to be a conda-forge compiled one. – Giguere

miniforge also holds (micro) mamba, which resolves resolves packages much faster (conda-forge needs this as their repo is way bigger than the one from anaconda) As a user you can ofcourse always start from a miniforge, but in CI this is very annoying, that's why miniforge was started by/for mini-forge CI. – Residuary

@nerohmot's comment on mamba may be less relevant as of Oct 2023 since conda also uses libmamba by default now, bringing them closer to parity in terms of speed with or without mamba – Carmella

Answer 1

miniforge is the community (conda-forge) driven minimalistic conda installer. Subsequent package installations come thus from conda-forge channel.

miniconda is the Anaconda (company) driven minimalistic conda installer. Subsequent package installations come from the anaconda channels (default or otherwise).

miniforge started a few months ago because miniconda doens't support aarch64, very quickly the 'PyPy' people jumped on board, and in the mean time there are also miniforge versions for all Linux architectures, as well as MacOS.

Soon there will also be a windows variant (hopefully also for both CPython and PyPy)

I guess that an ARMv7 (32Bit ARM) variant is also on the horizon (Raspbian)

Residuary

At this point, what is the difference between: 1. Miniconda3-latest-MacOSX-arm64.sh, which according to its description: Miniconda3 macOS Apple M1 64-bit bash is an M1 (Apple Silicon, arm64) compatible version of miniconda, and 2. Miniforge3-MacOSX-arm64.sh, which according to its description: OS X | arm64 (Apple Silicon) is also an Apple Silicon, arm64 (M1) compatible version of miniconda. As far as I can tell, the difference in that miniforge comes with only the conda-forge channel enabled. – Carbuncle

Answer 2

The license. As of the 30 September 2020 update to the Anaconda Terms of Service, access to the Main conda channel (hosted at repo.anaconda.org) is restricted: https://www.anaconda.com/terms-of-service

While both the conda and miniconda installers are published under a BSD 3-clause license, if you actually use the installed conda clients without removing the Main channel, you'll be in violation of Anaconda's ToS. The miniforge installer avoids this altogether, which is of particular interest to large organizations that wish to use conda.

Crustal

A quick scan of the ToS did not reveal the problem to me, but indeed: "we are not granting you permission to use the Repository for commercial activities". – Intestine

...though it seems to be okay for "use by entities in common control with each other with fewer than 200 employees in aggregate". See also anaconda.com/blog/anaconda-commercial-edition-faq – Intestine

Answer 3

The short answer: miniforge-installed conda is the same as Miniconda-installed conda, except that it uses the conda-forge channel (and only the conda-forge channel) as the default channel.

This can be deduced by looking at the two files the miniforge repo uses to build the miniforge installer:

• scripts/build.sh, which uses the conda package constructor to create a new conda installer

• Miniforge3/construct.yaml, a yaml file that specifies what the final conda environment should look like for the conda installer that construtor is building

Looking at construct.yaml it sets conda-forge as the only channel (there is no defaults channel added; also see this Github comment) and then installs a few packages (python, conda, pip, and bzip2). It also writes those changes to the condarc.

Comedian

I don't see the point of this answer, as it is only a confirmation of what is written in the Readme that you have already quoted in your question "can be directly compared to Miniconda, with the added feature that conda-forge is the default channel" – Romulus

"can be directly compared to" is ambiguous. "[miniforge] uses the conda-forge channel (and only the conda-forge channel)" is not ambiguous. – Comedian

"Can be directly compared to"!="Is the same" and "conda-forge is the default channel" does not sound very ambiguous to me – Romulus

"conda-forge is the default channel" - okay, but does that include the default conda channel after it includes the conda-forge channel? It's ambiguous, hence the question. (The answer is, no, miniforge uses the conda-forge channel and only the conda-forge channel.) – Comedian

default is in fact an anaconda channel, conda-forge doesn't need this, so as @Comedian said : NO – Residuary

@nerohmot: I have a channel called defaults(with a s) and I have to remove the ~/.condarc file to remove this channel. I did install miniforge3 with pyenv. Is this the correct way to use only community maintained conda-forge packages? – Watchword

@Rainning: I use miniforge only on CI/CD flows with github actions. On a normal box I don't want to go through the hastle of too much manual install stuff, so there I use maxiconda (maxiconda.org) have a look ;-) – Residuary