miniforge comes preconfigured with conda-forge as the default channel. So if you don’t alter this configuration, it won’t touch defaults. Do note that:
If you type -c defaults in any conda install (or create, update, remove) command, you will be querying and potential pulling packages from Anaconda from that moment on (in that environment).
conda config --set channels ... might reinject defaults due to an unfortunate side effect of how the configuration system works in conda
Always check the output of conda config --show-sources to make sure defaults is not mentioned. The output of conda-libmamba-solver will also reveal which channels are being queried.
AFAIK packages in conda-forge all have dependencies only on other conda-forge packages. At least for all the usual suspects that’s the case. And neither us as maintainers, nor conda-forge maintainers, are responsible for the user pulling from the main channel.
Right - the conda-forge maintainers can’t reasonably be responsible for making sure users don’t pull in Anaconda packages by accident.
This means that when we (the packages) give install instructions, we should be sure to give instructions that can users can depend on, not to accidentally pull in Anaconda packages. So in practice, no-one can guarantee that -c conda-forge has that effect - it becomes fragile in terms of that guarantee. Hence my suggestion that we start to strongly recommend miniforge and that it would be sensible to warn current conda users that they are at risk of becoming liable to a $50 / month fee.
It would be great to have some short authoritative instructions (+ maybe longer explanations/links) to live somewhere centralized, like Scientific Python website? So that individual packages can link to these instructions. Would be easier to maintain ecosystem wide, too.
(While we’re at it, tangentially related) In the exercise above, my environment.yml contains mkl. I just checked that it gets pulled from conda-forge, not defaults. Still I’ve no idea if there are any license concerns and — more importantly — I’ve no idea where to check. This is not specific to MKL: it’s very easy to add a package (great!), not so easy to know where and what licenses are.
Would be great to have some authoritative ecosystem-wide instructions / links, too. Even if the answer is “go find where the environment is, and grep for the LICENSES files in that folder”, or even “It’s all BSD/MIT unless it explicitly pops a EULA at install time”, that would already be a helpful starting point to a user.
Anaconda has changed their Terms of Service so that “heavy commercial users” would have to pay, which doesn’t include conda-forge channel.
The main channel is maintained by Anaconda, while conda-forge is maintained by the maintainers of the packages themselves. Each have their pros and cons. Packages on the main channel are usually compatible with one another, meaning you can install almost as many as you want, and you won’t have dependency conflicts. On the other hand, packages on the conda-forge channel receive the updates much faster than the main channel since the maintainers themselves push the updates to the channel. From time to time, there are also patches done by Anaconda on packages available on the main channel which are not supported and done by the maintainers of the package, which can be good or bad, but definitely out of hands of the maintainers and not supported by them.
You probably would want to stick to conda-forge if you don’t want to pay for the usage and you would be okay with the versions available on pypi. As stated in the docs: