conda-forge/conda-forge.github.io

Deploying conda-libmamba-solver

jaimergp opened this issue · 5 comments

This is ongoing work involving many PRs, so I'll aggregate them here so we can track the items:

The end result is:

  • Miniforge ships conda-libmamba-solver
  • conda-forge.yml allows three new options:
    • conda_solver, defaults to None (it uses whatever is default in conda)
    • conda_install_tool, defaults to mamba
    • conda_build_tool, defaults to mambabuild

This means that in the current state, conda-libmamba-solver won't be in use yet. But users can easily opt-in by reconfiguring conda_install_tool and conda_build_tool. After testing for a couple weeks I think we can roll it out generally.

conda-smithy 3.26 is now out and has support for the aforementioned keys. They are not in use by default yet, so the docs PR shouldn't be merged yet.

I've seen some incompatibilities in the test PR at conda-forge/dav1d-feedstock#10, where conda update fails to solve in macOS due to a conflict (but the preceding conda install and equivalent mamba update pass!). I think this is caused by a known issue that is now fixed in the upcoming conda-libmamba-solver 23.9.0. I'll try again once available and report back.

They are not in use by default yet, so the docs PR shouldn't be merged yet.

Oops saw 2 approvals on the PR and thought it was ready so merged, but didn't see this. What should be done for the docs at this point?

I'll try again once available and report back.

Were there any updates on this?

^ @jaimergp do you have thoughts here? Happy to help however makes sense

Hi! Sorry it took me a while to get back to this. I talked with @isuruf and after seeing the workarounds we are needing in some feedstocks, we came up with the idea of providing a conda-forge-ci-setup=4 version that requires those dependencies. Then folks can opt-in into the new dependency set. Once we are happy with v4, we can flip the default config in conda-smithy.