-
-
Notifications
You must be signed in to change notification settings - Fork 51
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
Start using conda
's libmamba
solver
in CI
#259
Start using conda
's libmamba
solver
in CI
#259
Conversation
Go ahead and opt-in to using `conda`'s `libmamba` `solver`. This will soon become the default. So it would be good to get a head start using this.
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@conda-forge/core please share your thoughts on this 🙂 |
PR looks great! We do have mamba instead of conda specified in a bunch of spots in smithy and the like. So this PR alone won't fully switch us over. That's fine OFC. I just wanted to mention it for clarity and those following along! |
@jaimergp you had a recommendation for a minimum stable version of the libmamba solver. Are we going to be consistent with that by pulling the latest version? Should we hardcode a |
Thanks Matt! 🙏
Definitely true. Wanted to start here to make sure we have this piece handled It's easy to explore the next step in a conda-smithy PR (and test it in a feedstock) before rolling that change out more generally
Would it be ok to stick with the version set in the installer? Or do we actually need to specify this in more places (like is there risk of it being downgraded)? |
Another wrinkle is that we might be upgrading deps and envs on the fly when running jobs even if we have a version in the installer? |
We could run a |
We've had very few regressions (if any) so far, so sticking to latest seems to be the best thing we can do for now. I am more concerned about the That said, since those inconsistencies are "edge-casey" (heavily constrained env updates, crazy ops like switching everything to a different channel, etc) and we are mostly using it for new environments and a single channel (conda-forge), we should be fine with what we are currently shipping in Miniforge: 23.3.0. |
The larger conversation is whether we start using periodically updated lockfiles to provision the installation instead of a blind "update all" that sometimes leaves us in uncertain spots, but yea, a topic for another issue. |
Thanks Jaime! 🙏 So it sounds like there are no action items (for this PR) from your perspective. Or did I missing something? |
Yep, no extra items I can think of. We just need to make sure we use |
Can you add |
I wonder whether we should also provide some configurability like in the strict channel priority setting:
, which might require a |
How would that interact with condarc handling? |
Whatever config source is last wins. The precedence is:
What are the concerns for those interactions? |
Oh I meant our munging of the condarc. I was hoping we could do all of our changes to it in one spot in our CI system. IDK how many spots we have now. |
Also due to the John handles feedstocks, we cannot push to this PR directly. If we want to finish it while he is away, we'll need to move the code to another account that is not an org. |
Yea, me neither 😂 This will need a deeper audit, but I can think of the following spots in our supply chain right now:
Users could choose between conda-build and mambabuild before too, via
I'll open a new PR and credit John in the commits. |
Continues on #275 |
Thanks Jaime! 🙏 |
Go ahead and opt-in to using
conda
'slibmamba
solver
. This will soon become the default. So it would be good to get a head start using this.Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)