Adding conda-libmamba-solver

[jakirkham]

Idk if we are ready to do this, but would like to at least raise the idea then we can discuss when it may make sense to do.

Would like to suggest adding the conda-libmamba-solver package to the installers here. This would make it easier for people to try the libmamba solver as described in this blogpost. Also would make it easier for us to try this ourselves in our own tooling.

As users still need to enable the libmamba solver (installing it is necessary, but not sufficient), there should be little risk from including the package itself. Though as it does make it easier to try, this could create an uptick in traffic/issues. So something to consider.

cc @jaimergp (in case you have thoughts on this as well)

[jaimergp]

Thanks @jakirkham! This came up in #277 (review). We want to wait a bit before including it in installers to handle the feedback / fixes from early adopters first, but I agree with all your points above. We'll get there soon!

[jakirkham]

Thanks Jaime! 🙏

Oops sorry missed that 😅

Yeah figured the answer was this is too early, which is ok 👍 Not intending to rush things

Though was also interested in a rough idea of when this might be ok to include. Think Jannis' comment of maybe end of Q2 or early Q3 makes a lot of sense. Also ok if that changes 🙂

[jakirkham]

Now that we are approaching the end of the year, curious what your thoughts are on this @jaimergp? 🙂

[jakirkham]

cc @jezdez (for awareness)

[jaimergp]

Q4 is supposed to see the release of a conda-libmamba-solver that uses the new plugin framework in conda/conda, which also implies dropping the experimental label. I guess that could be considered a good moment to start distributing it in Mambaforge, but we should also assess the compatibility status of the conda/mamba/boa trinity to make sure we don't end up in weird situations like the one we saw with the Docker images recently.

[jakirkham]

Thanks for the context! Agree that sounds reasonable.

Think part of that recent Docker image weirdness traces back to the CalVer change. Still worth making sure that is ironed out though.

[jakirkham]

So at this point the experimental label has been dropped. It's been over a year since the first blogpost announcing conda-libmamba-solver and ~6months since the experimental label has been dropped as mentioned in the second blogpost

What it be reasonable to include conda-libmamba-solver?

Relatedly what about configuring it in the installer to be the default solver?

[jezdez]

@jakirkham Huh, that's timely, I didn't see your comment before I mentioned this topic in the conda community meeting yesterday.

I strongly support including conda-libmamba-solver!

In fact, the next miniconda and Anaconda Distribution installers this month will include it by default to simplify the migration for normal users.

Relatedly what about configuring it in the installer to be the default solver?

I would support that and have suggested that to the Anaconda installer team, but ultimately, we decided against it given the short amount of time for the following next step:

Unless we receive unexpected feedback from users in the coming months, the conda maintainers will switch to libmamba as the default solver in the September release window (e.g. conda 23.9.0 etc). This will mean requiring to install conda-libmamba-solver, of course.

Meanwhile, the classic solver will remain in the conda code base to enable users to “switch back” if needed. Long-term, I'd like to see a removal of the classic solver code and (if there is use for it) the release of a conda-pycosat-solver (or similar) package.

[jezdez]

Here's the blogpost draft I'm working on: conda/conda-dot-org#143

[jaimergp]

Yea I think it's due time we do this. One question I have is what's going to happen to the Mamba/Mini-forge split. In #277 @isuruf added conda-libmamba-solver to Miniforge (which I 100% support). However, IIRC, the original decision to put mamba in a different installer (Mambaforge) was due to concerns with the extra size added by the libraries.

Adding conda-libmamba-solver to Miniforge would mean that the only real difference between Mamba- and Miniforge is the presence of the mamba Python package, but all the C++ libraries (libmamba, libmambapy, libsolv, etc) would be common across them. So the size difference would be negligible.

In that case, I would be inclined to put everything (mamba and conda-libmamba-solver) under the same installer: Miniforge.

So the questions are:

• Do we still need Mambaforge and Miniforge separate or is it time to combine both? If that's the case, what's the migration plan? (If only GH releases had redirects or symlinks)
• If we do want to keep them separate, what's the rationale? Backwards compatibility? Marketing?

These questions are made under the assumption that Miniforge tries to mirror what Miniconda does, hence adding conda-libmamba-solver now (aligned with Anaconda's plans).

Let me know what you think!

[jakirkham]

^ Thoughts @conda-forge/core ?

[chenghlee]

• Do we still need Mambaforge and Miniforge separate or is it time to combine both? If that's the case, what's the migration plan? (If only GH releases had redirects or symlinks)
• If we do want to keep them separate, what's the rationale? Backwards compatibility? Marketing?

Putting in my two cents: I say we include mamba in miniforge, then copy miniforge-${rel} as mambaforge-${rel}. Storage is cheap. And we don't break users/processes that assume mamba is available.

[jaimergp]

I am fine with that! I can also see in meeting notes from yesterday that the consensus would be to add mamba to Miniforge too (in addition to conda-libmamba-solver) and deprecate Mambaforge but without breaking the links for new releases.

We'll start with that but at some point I'd like to add a note in the installers that informs about the change "Miniforge and Mambaforge are now identical" and add a deprecation date to finally remove Mambaforge.

[ocefpaf]

Miniforge too (in addition to conda-libmamba-solver) and deprecate Mambaforge but without breaking the links for new releases.

B/c of the repoquery functionality I'm +1 to that. When it comes to the solver things are virtually the same but there are many users of repoquery out there that would feel like a burden to install mamba after the min- install just to get it.

[beckermr]

We're gonna break the world even if we try hard to properly deprecate the mambaforge installer links. They tend to sit in poorly watched places like CI jobs etc. I honestly think it is more pain than it is worth.

[jaimergp]

B/c of the repoquery functionality I'm +1 to that.

We should have an equivalent in the conda command to. The logic is already in conda-libmamba-solve, maybe we just need a subcommand plugin to expose it in the CLI. 🤔

[jaimergp]

Btw, #277 is ready for review if anyone has spare cycles.

[ocefpaf]

We should have an equivalent in the conda command to. The logic is already in conda-libmamba-solve, maybe we just need a subcommand plugin to expose it in the CLI. 🤔

I'm glad you took the bait 😄 (and sorry/not-sorry for the trap ;-p)

[hmaarrfk]

thanks everybody