Effects of options --conda VS --mamba/--micromamba

[Gullumluvl]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

Hi!

I have some questions about what happens under the hood of conda-lock, which I could not quite figure out from the documentation. I hope asking here is fine.

The description of the options which imply using mamba or micromamba is as follows:

Name	Type	Description	Default
--conda	text	path (or name) of the conda/mamba executable to use.	None
--mamba / --no-mamba	boolean	don't attempt to use or install mamba.	True
--micromamba / --no-micromamba	boolean	don't attempt to use or install micromamba.	False

They apply to all subcommands of conda-lock.

but I don't know what is the difference between using --conda micromamba and --micromamba.

I would expect that only conda-lock install uses the --conda option, to run the specified executable, while conda-lock lock ignores this one but need some libraries to be used, controled with --mamba/--micromamba. Is that right?
Does using --mamba/--micromamba impacts the reproducibility of the solved environments?

Also, when and where do these options install (micro)mamba? I am not sure I need them if I already installed (micro)mamba on my system.

Thanks in advance for your help!

Additional Context

No response

[maresb]

Hi @Gullumluvl, thanks for opening an issue. This is indeed a confusing aspect of conda-lock, and we really could use better documentation here. You do an excellent job of structuring and posing your question, so perhaps we could convert this into documentation.

The machinery for selecting the conda (or mamba/micromamba) executable is built on ensureconda. You can play around with it using the command ensureconda --no-install, e.g. ensureconda --no-install --no-mamba. Unfortunately I'm not even sure if the conda-lock logic exactly mirrors that of ensureconda. (This machinery predates my involvement with conda-lock.) The ensureconda stuff is further wrapped by some utilities in conda-lock:

conda-lock/conda_lock/invoke_conda.py

Lines 46 to 66 in 9766789

	def _determine_conda_executable(
	conda_executable: Optional[PathLike], mamba: bool, micromamba: bool
	) -> Iterator[Optional[PathLike]]:
	if conda_executable:
	if pathlib.Path(conda_executable).exists():
	yield conda_executable
	yield shutil.which(conda_executable)
	yield _ensureconda(mamba=mamba, micromamba=micromamba, conda=True, conda_exe=True)
	def determine_conda_executable(
	conda_executable: Optional[PathLike], mamba: bool, micromamba: bool
	) -> PathLike:
	for candidate in _determine_conda_executable(conda_executable, mamba, micromamba):
	if candidate is not None:
	if is_micromamba(candidate):
	if determine_micromamba_version(str(candidate)) < Version("0.17"):
	mamba_root_prefix()
	return candidate
	raise RuntimeError("Could not find conda (or compatible) executable")

Let's make a first pass at answering your questions.

but I don't know what is the difference between using --conda micromamba and --micromamba.

The way I think about it, the main use case for --conda is to specify a particular executable in case detection via --micromamba doesn't work as expected. You might have an installation of conda or mamba or micromamba in your project environment, and/or your base environment, and/or a pipx environment. So I wouldn't ever use --conda micromamba, but instead --conda /path/to/some/specific/micromamba.

You could ask "is there any functional difference between --conda micromamba and --micromamba?" and I'm honestly not entirely sure about the answer, but I think they're identical at least most of the time if not all the time. To be sure you would have to consider the edge cases of determine_conda_executable like what happens if there is a micromamba in the current working directory, and whether or not that differs with the behavior of ensureconda.

I would expect that only conda-lock install uses the --conda option, to run the specified executable, while conda-lock lock ignores this one but need some libraries to be used, controled with --mamba/--micromamba. Is that right?

Not quite. When running conda-lock lock, we use the executable to create a fake environment in dry-run mode. This generates a solution for the package specification, and those specific versions then become the "locked" versions. So the --conda executable determines which solver we use for the lock operation.

Does using --mamba/--micromamba impacts the reproducibility of the solved environments?

Yes, because the solution depends on the solver used. From a theoretical perspective I find reproducibility to be a really interesting topic, but practically speaking, even with medium-sized environments the latest dependencies change so quickly that you need to fix a timestamp before any realistic discussion of reproducibility. AFAIK, rattler is the only solver that supports this, and I'm not aware of this actually being used anywhere.

Also, when and where do these options install (micro)mamba?

Into the user data directory for the ensureconda app, as defined by appdirs. It will not be installed if it is successfully detected.

Finally, a few minor corrections in your table:

1. for both mamba and micromamba, add the bold:

   do or don't attempt to use or install

   Oh, this is awkward, I see now that you just copied this from our CLI hints 🤦

2. The default value for --mamba is only True if mamba is detected, otherwise it's false.
   See

   conda-lock/conda_lock/conda_lock.py

   Lines 105 to 110 in 9766789

   	HAVE_MAMBA = (
   	ensureconda(
   	mamba=True, micromamba=False, conda=False, conda_exe=False, no_install=True
   	)
   	is not None
   	)

   noting no_install=True, together with

   conda-lock/conda_lock/conda_lock.py

   Line 1446 in 9766789

   DEFAULT_INSTALL_OPT_MAMBA = HAVE_MAMBA

   and

   conda-lock/conda_lock/conda_lock.py

   Lines 1459 to 1463 in 9766789

   	@click.option(
   	"--mamba/--no-mamba",
   	default=DEFAULT_INSTALL_OPT_MAMBA,
   	help="don't attempt to use or install mamba.",
   	)

Does this help clear things up? Would you be interested in opening a PR for this?

[Gullumluvl]

Fantastic! Thanks a lot for the details :D

I actually missed that ensureconda was already mentioned in the docs, sorry about that.
Regarding

"is there any functional difference between --conda micromamba and --micromamba?"

With your explanations it almost seems to me that the --conda option should be forced to look like a path (i.e. at least ./conda if in the current directory), in order to clearly separate the intent. And/or making it mutually exclusive to --mamba/--micromamba. Probably too strict though and might not be worth breaking people's usage.

Would you be interested in opening a PR for this?

Yes I would probably be able to make a PR after I take some time to look at the code!

[maresb]

(closing the issue was a mouse slip)

And/or making it mutually exclusive to --mamba/--micromamba.

This would make a lot of sense to me.

[scott-kausler]

I'm happy to see this explaination. Is there a way to set an environment manager so that I don't need to manually apply --micromamba to every conda-lock command?