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