Add support for mamba

[marcelotrevisani]

Hi folks,

It would be really nice to support mamba out of box with conda-devenv
Because, mamba has a solver which is faster than the solver used by conda, mamba uses libsolv which is the same used by some package managers on some Linux distributions such as OpenSuse, Red Hat, and Fedora.

I was wondering if we can use mamba directly when conda-devenv detects if mamba is installed in the base environment and we may add a flag to be able to disable this behaviour as well.

What do you think?

I am a bit busy these days but I may work on this if you agree with that. But if someone wants to tackle it, please go ahead! :)

[prusse-martin]

This is truly a desired feature =)
Auto detection with flag to force vanilla conda? yes.

We have been considering using mamba exactly for this speed up.
I guess we just did not go for it because mamba is on the 0.X version.

[nicoddemus]

👍 from me as well.

[majidaldo]

i've implemented this in my flow to get this to work w/o changing how conda devenv works (currently).

0. parse from --print-full
1. create a blank env (with one 'stub' dep) and just env vars from --print-full with conda devenv activation script not set when using alt filename #127, use conda env config vars set  #126
2. get the deps and give those to mamba option to pass args to conda #125
3. handle the pip installs separately (more generally this can be any installer script) feature: triggers #108 [micromamba] allow pip in env.yml files mamba-org/mamba#589 (comment) ,

as my set up has gotten more sophisticated the need for mamba has risen!

[majidaldo]

i've implemented this in my flow to get this to work w/o changing how conda devenv works (currently).

1. parse from --print-full
2. create a blank env (with one 'stub' dep) and just env vars from --print-full with conda devenv activation script not set when using alt filename #127, use conda env config vars set  #126
3. get the deps and give those to mamba option to pass args to conda #125
4. handle the pip installs separately (more generally this can be any installer script) feature: triggers #108 [micromamba] allow pip in env.yml files mamba-org/mamba#589 (comment) ,

as my set up has gotten more sophisticated the need for mamba has risen!

The discrepancy b/w the tooling is bothering me and i'm having to glue it together. This 'team' has a lot to say about how things should advance. We should start talking about conda being 'low level' (single env spec implementer) with other 'specs' being 'higher level' that can relate envs; conda devenv being one of them.

[prusse-martin]

I am not following the mamba project at the moment. I was not aware of pip problems when using mamba.

I remember we already merged some changes to better merge pip dependencies in the resulting environment.yml, I don't personally recommend using pip in conda environments, but there was a request for that =)

About the example in mamba-org/mamba#589 (comment), I need to comment that executing arbitrary code makes me feel a bit uneasy.

[majidaldo]

I am not following the mamba project at the moment. I was not aware of pip problems when using mamba.

I remember we already merged some changes to better merge pip dependencies in the resulting environment.yml, I don't personally recommend using pip in conda environments, but there was a request for that =)

About the example in mamba-org/mamba#589 (comment), I need to comment that executing arbitrary code makes me feel a bit uneasy.

I don't like pip either (at least in conda) either. But the reality is that you have to occasionally use pip, npm, ...etc. In the end you're just executing code. There is no line b/w the act of installing via a pkg mgr vs installing via a cmd. In the end, it comes down to trust. That's why I'm advocating for something towards a general build system for envs (not pkgs...pkgs simply get installed in an env via (hopefully) pkg mgr cmds ).