miniforge for faster installs on any conda-forge supported platform?

[buhrmann]

Hi, this is not so much an issue as a question. I had inquired about possibilities to streamline installs of miniconda with pre-configured conda-forge channel, package versions etc. in the conda-repo: conda/conda#9655. The problem was that 1) installing conda, 2) selecting the conda-forge channel and updating conda, 3) creating an environment, seemed to do a lot of unnecessary work (downloading, installing and resolving packages and dependencies up to 3 times) before the final environment could be created.

The solution suggested there is a new conda standalone installer, which seems to work fine.

My question is, would you recommend that option? Or are there plans to distribute a pre-configured miniforge that could be installed on any of the platforms currently supported in conda-forge (not only those that aren't supported by Miniconda).

[isuruf]

My question is, would you recommend that option?

Nope. The standalone installer is slightly different in that if you keep using it, it doesn't re-activate the environment after you install a new package. So, a full miniconda installation is better.

Or are there plans to distribute a pre-configured miniforge that could be installed on any of the platforms currently supported in conda-forge

If you are willing to do the work, no objections from me.

[msarahan]

Unless the miniforge installer is completely up to date, or you do not perform any update, the standalone will be faster for CI. It also has the huge advantage that any environment it creates does not compete with the base environment that an installer would create.

For laying down a base environment for interactive use, miniforge is probably better for the reasons @isuruf mentions. However, keep in mind that creating such an installer implies supporting it. Simply creating something that makes your life a bit better, but breaks stuff and makes headaches for many others is probably not a helpful contribution.

[buhrmann]

Ok. Thanks for the quick response! I guess my question was more about whether (in the long term) miniforge was planned as a general replacement for miniconda, in which case it would potentially have helped with streamlining fresh installs. I understand this is not the case, and I don't think I have the resources to support my own installer either.

It seems then that the standalone conda may be a possible solution e.g. within a containerized app, where the environment is fully constructed before being used by an app (non-interactively), while miniconda remains the better choice for interactive environments.

[scopatz]

I guess my question was more about whether (in the long term) miniforge was planned as a general replacement for miniconda

It isn't a replacement for miniconda, but rather an alternative to it, for those who know they want to use conda-forge from the get-go!

We are doing this as a community, and so any help that you (or anyone) can give towards this effort is greatly appreciated!

[hmaarrfk]

implies supporting it

This is likely the reason why I am against competing with minconda.

Honestly, my goal is to show that minconda miniforge is valuable, but then hope that Anaconda as a company, decides to support it so that miniconda miniforge becomes obsolete.

[scopatz]

Oh interesting. My goals for miniforge is that is becomes a commuity supported installer and is an installer that defaults to conda-forge

[SylvainCorlay]

1. installing conda
2. selecting the conda-forge channel and updating conda
3. creating an environment, seemed to do a lot of unnecessary work

I am +1 on this. I would love a miniconda that defaults to conda-forge. Communicating to users that they need to change their default channels to install our packages makes their experience cumbersome. I would love if it was more streamlined.

[hmaarrfk]

In terms of streamlining install, I find that adding a channel is easy compared to repeatedly telling new users they should not use base to install their applications.

[adrinjalali]

Oh interesting. My goals for miniforge is that is becomes a commuity supported installer and is an installer that defaults to conda-forge

@scopatz this means forking conda, doesn't it? I personally would love to have a community backed installer, but I'm really not sure if there are enough resources, including human resources, to back such a project.

I keep daydreaming about a community backed installer which would support a bunch of features such as having a swarm of mirrors as linux distros do, but I guess @hmaarrfk 's estimate is that the required resources don't exist for such and undertaking?

[rgommers]

@scopatz this means forking conda, doesn't it?

It doesn't at all. Miniforge installers for a number of OSes exist today, and adding new platforms has gone fairly smoothly.

I don't think Anaconda the company will have interest in, e.g., supporting a ppc64le or PyPy based installer. And I also don't see why it would be desirable to push things back to Anaconda. The current community based approach has attracted a lot of support quickly, and seems like the right target to aim for.

There's gh-28 for Windows support, and installers for Linux, macOS, ARM64 and more are available: https://github.com/conda-forge/miniforge#download. So this issue can probably be closed.

[rgommers]

Oh and, the NumPy website now includes Miniforge as one of the recommendations: https://numpy.org/install/

[scopatz]

@scopatz this means forking conda, doesn't it?

I agree with Ralf, this doesn't mean forking conda, which is its own open source project. This just provides new ways for people to install conda

[romainx]

Just to share we have very recently switched from the Miniconda to the Miniforge installer on Jupyter Docker Stack images. This PR list some of the reasons that have led to this choice jupyter/docker-stacks#1189.

[jakirkham]

Cool thanks for the data point 🙂

[isuruf]

All platforms supported by conda-forge have miniforge installers now