-
-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding conda-libmamba-solver
#284
Comments
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! |
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 🙂 |
Now that we are approaching the end of the year, curious what your thoughts are on this @jaimergp? 🙂 |
cc @jezdez (for awareness) |
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. |
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. |
So at this point the experimental label has been dropped. It's been over a year since the first blogpost announcing What it be reasonable to include Relatedly what about configuring it in the installer to be the default solver? |
@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.
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 |
Here's the blogpost draft I'm working on: conda/conda-dot-org#143 |
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 Adding conda-libmamba-solver to Miniforge would mean that the only real difference between Mamba- and Miniforge is the presence of the In that case, I would be inclined to put everything (mamba and conda-libmamba-solver) under the same installer: Miniforge. So the questions are:
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! |
^ Thoughts @conda-forge/core ? |
Putting in my two cents: I say we include |
I am fine with that! I can also see in meeting notes from yesterday that the consensus would be to add 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. |
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. |
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. |
We should have an equivalent in the |
Btw, #277 is ready for review if anyone has spare cycles. |
I'm glad you took the bait 😄 (and sorry/not-sorry for the trap ;-p) |
thanks everybody |
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 thelibmamba
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)
The text was updated successfully, but these errors were encountered: