Maintaining relevance in 2024

[hmaarrfk]

We started Miniforge as the solution to install conda+conda-forge when no support was provided for Arm (both linux + eventually osx).

Over the years, to address usability challenges with the growing number of packages, Mambaforge was created.

A few other requests were made to integrate other packages from the r ecosystem, or improve on the conda backend by using micromamba or pixi.

However, in 2024, it seems difficult to move forward since we are considering backward compatibility for users that use Miniforge in their CIs.

Ideas on how to keep Miniforge relevant in 2030 encourage!!!!

cc: @wolfv

(ctrl+enter when creating a new issue seems to post a blank issue..... it keeps happening to me)

Activities to undertake:

Shedding old responsibilities

• Migrate internally from Mambaforge to Miniforge3
• Sunset plan for Mambaforge
• Sunset for Mambaforge docker images
• Update information in this repo: Inaccurate info re Mambaforge deprecation in README FAQ #625

Building new features

• feature 1
• feature 2

[jaimergp]

One thing to do is sunsetting Mambaforge for good (notify users through several methods like in the installer and in our README, maybe also in setup-miniconda, with plenty of time ahead, like a year).

Hopefully one day conda can be distributed in a single binary too, so Miniforge is not as relevant?

What things would you like to provide to keep "Miniforge relevant"? People that want Pixi or Micromamba are getting it via other means primarily, I'd assume?

[hmaarrfk]

I agree that sunsetting Mambaforge for good would alleviate support burden. I'm not sure how to execute.

I think the brand power is pretty powerful behind Miniforge. The work that you've done on the system integration for the installer is quite good.

5.9k stars on github is nothing to sneeze at.

• Staged recipes: 692 stars
• conda-forge.github.io: 120 stars

of all the repos listed https://github.com/conda-forge#hi-there- it is the "most starred". I think it is important to capitalize on this to ensure that our voice is heard in upstream projects (i.e. please approve this patch for cross platform compatibility).

[isuruf]

I agree that sunsetting Mambaforge for good would alleviate support burden.

I don't understand what you mean by the the maintenance burden here.

I'm not sure how to execute.

First, let's change Mambaforge to Miniforge in conda-smithy. Currently Mambaforge is used as much as Miniforge because of this.
And also setup-miniconda

[jaimergp]

First, let's change Mambaforge to Miniforge in conda-smithy

Let's do that across our infra:

• Use Miniforge everywhere conda-smithy#1986
• Use Miniforge, not Mambaforge admin-requests#1037
• Use miniforge, pin some GHA actions #613
• Use Miniforge, update pins by-the-numbers#39
• Use miniforge, update pins conda-forge.github.io#2240
• Use miniforge, use Python 3.9, update pins admin-migrations#114
• Use miniforge, update pins automerge-action#55
• Use miniforge, update pins regro/conda-forge-feedstock-check-solvable#50
• Use miniforge, update GHA pins, use bash -el regro/cf-graph-countyfair#29
• Use miniforge, update pins conda-forge-metadata#40

And also setup-miniconda

• Start deprecation of miniforge-variant: Mambaforge conda-incubator/setup-miniconda#360

[beckermr]

I like these PRs @jaimergp!

In terms of the support burden, I think we might be able to do 90% of the work and keep things sane.

1. Can we only make the miniforge installer and simply upload a copy with the mambaforge name to our releases? This would eliminate builds to debug.
2. We are going to have to drop the pypy builds once conda-forge fully drops the python versions we have from pypy anyways. So that will take care of itself maybe?
3. We can already drop mambaforge and references to it from the docs/readme, right?

After those three things, we'd be in a much simpler spot except for one extra copy of the installer uploaded to GHA.

Another idea would be to announce deprecation and then slowly do something so people notice the change in a non-destructive way. Typical things here are

• time delays in the installers
• brownout periods of increasing cadence to warn folks

What do you all think?

[jaimergp]

Can we only make the miniforge installer and simply upload a copy with the mambaforge name to our releases? This would eliminate builds to debug.

Sadly the original installer name Mambaforge gets bundled in the default installation path (e.g. ~/Mambaforge). So if we copy Miniforge3-*.sh to Mambaforge-*.sh, then it'll install to ~/Miniforge3, which might be breaking for some folks.

We can add warnings to the installer descriptions via constructor (e.g. in the header of the EULA), and stupidly long sleeps to the pre-install scripts. Eventually brownouts too.

[beckermr]

Sadly the original installer name Mambaforge gets bundled in the default installation path (e.g. ~/Mambaforge). So if we copy Miniforge3-.sh to Mambaforge-.sh, then it'll install to ~/Miniforge3, which might be breaking for some folks.

Argh. We could do insane things like replace the text in the binary. OTOH maybe not.

[jaimergp]

For Linux and macOS it's just a sed away. For the EXE stuff in Windows it's a bit more involved...

[beckermr]

We could embed some warning-type messages directly in the installer if we detect we are running in GHA (for example). See https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-a-warning-message

Maybe other CI services have similar functionality?

[jaimergp]

Let's see how this looks like: #615

[jaimergp]

Announcement: conda-forge/conda-forge.github.io#2242

I chose arbitrary dates roughly following the bimonthly conda release cycle.

[jaimergp]

I just occurred to me that we might also need to start the sunsetting process in the mambaforge Docker images... Writing it here so I don't forget.

[zerothi]

The current move by Anaconda is really pushing users towards miniforge, so I would expect your relevance to be higher than ever ;)

I guess most users of conda installations are using anaconda or miniconda out of their generalized publicity, not because of active choice. So pushing more on conda-forge that miniforge is the way forward, that might be a good thing. On the other hand (AFAIK), conda-forge binaries are still hosted via anaconda (let me know if I am wrong here!), so this might be problematic if anaconda don't want to host it anymore... ?

While users can work-around anaconda with channels etc., it is better (and easier to explain users/students/educators) to use a single installer that defaults to free services (as miniforge does it). So lots of potential IMHO!

👀 👀

[beckermr]

To be clear, Anaconda Inc has and continues to be incredibly supportive of conda-forge, both in terms of hosting our packages, but also in terms of developer time, donations to numfocus, and technical support for anaconda.org. While we continue to work on diversifying our hosting for reliability, making backups, etc., we have NO INDICATIONS that anaconda inc would stop hosting conda-forge.

[zerothi]

To be clear, Anaconda Inc has and continues to be incredibly supportive of conda-forge....

That's amazing to hear! Thanks anaconda!

And to be clear, I don't think anaconda is doing anything wrong, it's just that many users are not aware of their terms of use/service.

[hmaarrfk]

@jaimergp the brownouts are stopping the release of 24.9.2 any ideas?

[beckermr]

How are the brownouts stopping this? Is it testing steps?

Seems to me since we're deprecating it anyways, maybe we just don't release any more versions of mambaforge?

[hmaarrfk]

Is it testing steps?

yes the test step where the installer is tested seems to be failing.

maybe we just don't release any more versions of mambaforge?

they have mostly been pinned, but generally speaking we have people that use the "latest download release" on their CIs so we are trying to "help".

[beckermr]

Ok. I don't follow fully since I don't do maintenance here, but I think it'd be fine to just hack the build to copy the last release of mambaforge from now on instead of building it at all. Then we can drop the copy when the whole thing is removed.

[hmaarrfk]

but I think it'd be fine to just hack the build to copy the last release of mambaforge

This might be actually the better way since it would minimize the testing surface...

[jaimergp]

We can also plant an environment variable in our CI and skip the brownouts that way. Whatever is easier.

Or ignore errors for Mambaforge.

[hmaarrfk]

Is this functionality already built into the brownout mechanism?

[jaimergp]

Is this functionality already built into the brownout mechanism?

Nope, but I can do that.

[jaimergp]

Although the brownout was yesterday. Next one is on the 20th, so that's the release window without actually having to do any changes 😂

[hmaarrfk]

Yeah. Let’s just retriever the release then

[hmaarrfk]

Small update. 24.9.2-0 just marked as latest: https://github.com/conda-forge/miniforge/releases/tag/24.9.2-0

[paugier]

I agree with the need to think about the future of what is provided with Miniforge and the relevance of this project, now that micromamba and pixi exist.

One important fact to consider is the change of Anaconda, which started to use its restricted license. As a consequence, employees of most universities and research institutes and big companies (those bigger than 200 employees) have to stop using Anaconda Distribution. So they have to find an alternative.

About the relevance of Miniforge in 2024 and the near future, becoming a good alternative to the Anaconda Dist. for these users could be a good goal.

In my point of view (maintainers of few scientific Python packages and organizer of Python trainings in my university), it would be interesting that the conda-forge community thinks and answers to few questions:

• What is the recommended installer and method to install and setup something to use conda-forge packages?

  Currently, we have:

  • miniforge
  • micromamba
  • pixi

  For which applications the different tools have to be used? This should be explained somewhere in https://conda-forge.org.

• What is the recommended webpage with instructions to follow to install and setup conda/mamba? We have https://conda-forge.org/download/ (which is just about download) and the README of https://github.com/conda-forge/miniforge (which is currently quite bad, as I tried to explain here README.md quite confusing: reorganisation needed #685).

  In https://conda-forge.org/download/, there is nothing about setting up conda and only a link towards https://github.com/conda-forge/miniforge.

  I'd like to stress that the setup part is important. Without these setup steps, a conda/mamba installation is not really usable.

  • On Windows, one needs to add condabin in the PATH and IMHO, this should be done by the Miniforge installer. Using Anaconda Prompt is really not a good solution. Most Windows users can't guess that they are going to have a much better user experience with the Windows Terminal and PowerShell.
  • conda init --all and conda config --set auto_activate_base false have to be mentioned and explained.

• Do we want to change the current default of having base activated? IMHO, the base environment should not be used to install packages and should be kept only for conda. It should be considered an implementation detail of conda that python is in base. It could make sense to activate no environment by default and teach people to create and activate a main environment. This could even become an option of the Miniforge installer. We could also maintain a simple conda-forge-pydata-env.yml file to be able to create an environment that can be used a bit like Anaconda Dist base environment.

• In the long term, do we really need conda + mamba? Having two tools to do exactly the same things is not optimum.

• It should be simple to change or define the index. IIUC, we now have at least two indices for conda-forge (Anaconda and Prefix.dev (https://prefix.dev/channels/conda-forge)).

• What about installation of applications with Miniforge? With Pixi, applications can be globally installed in isolated environments with pixi global install spyder. We should have something similar with miniforge.

  Note that Spyder official installers on Windows and macOS are based on miniforge and basically install a miniforge just for Spyder and Spyder in an environment.

  It makes me think that with Miniforge, conda global install spyder should install Spyder globally.

  Some years ago, I started to work on conda-app (https://foss.heptapod.net/fluiddyn/conda-app, Git mirror here if you prefer). Maybe it is time to use it to make something better and officially supported by conda-forge.

[hmaarrfk]

I think these are all good questions. I’ll try to break them down when I get time to sit.

One question with an immediate potential action item is dropping compatibility with boa. A while back I had added explicit tests for it to ensure we don’t randomly start downgrading packages. This is causing

#694

To be held up. Do we want to drop explicit compatibility with boa in dec 2024?

[jaimergp]

Yea, I think we are focusing on conda-build + rattler-build these days. conda mambabuild hasn't been our default build command for a while.

[hmaarrfk]

Thanks for the input. Release 24.11.0-1 with mamba 2.0.5 started

[hmaarrfk]

As a consequence, employees of most universities and research institutes and big companies (those bigger than 200 employees) have to stop using Anaconda Distribution.

They don't have to stop. They could decide to pay Anaconda for their hard work and support.

becoming a good alternative to the Anaconda Dist. for these users could be a good goal.

I'm not sure I agree with this. Building something with the same level of support takes alot of time of dedicated resources. We are a team of volunteers. If you are willing to help answer questions on the windows side, you are more than welcome to start. I just don't have the bandwidth to answer all the questions #599
You don't have to say too much, just working through problems with end users would help tremendously.

For which applications the different tools have to be used?

The challenge is that this is a rapidly evolving problem. Mamba was created to address the slowdowns of conda when the packages in conda-forge exploded. pixi was created as a different way of thinking about packages, so it isn't 1-1 compatible.

What is the recommended webpage...

https://conda-forge.org/download/ points you to the readme in
https://github.com/conda-forge/miniforge?tab=readme-ov-file#windows

I know you are helping improve this. I need to spend some time with your new proposed organization. I've added it to the top as a way to improve and to maintain relevance

activating base

Perhaps best discussed in #636 I added it to the "maintaining relevance roadmap".

In the long term, do we really need conda + mamba?

I think this might take an other "while" to deprecate. I routinely find "old" environments that are "2 years old" on my systems. Thus it isn't just about the "directory" but also about muscle memory for many users... One challenge is that it is difficult to "uninstall" packages from user's existing environments conda-forge/conda-forge.github.io#1894 I think there are good reasons to drop mamba if it gets dropped by mamba-org.

It should be simple to change or define the index.

I don't think Anaconda is going after users of the conda-forge channel, just the main channel. I haven't seen any issue reports with users having the prefix dev channel in their config.

What about installation of applications with Miniforge? [...] globally installed [...] We should have something similar with miniforge.

The main goal of miniforge is to ensure we can install the conda command on the platforms we support. Feature requests for conda should go to the conda upstream developers https://github.com/conda/conda/

Some years ago, I started to work on conda-app

This looks cool. But personally, I would like to narrow the scope of miniforge instead of expanding it. If conda-app can be installed by conda then I believe our job is done. I want to encourage users to create their own "installers" based on this one for their specific use cases.