mamba dependency changes mamba behavior

[michaelaye]

As advised previously, I only have mamba installed in the base environment, because otherwise mamba starts to behave differently from conda.

The best example is updating a different env from the current one:

conda activate py38
mamba update -n base --all

Only when the only available mamba is in the base env, this behaves as expected. If there's a mamba installed in the env py38, then, with that activated, above command updates that env, and not base, despite the -n option used.

Now, for package development using mambabuild one requires boa and therefore mamba be installed in the env used for development.

Questions:

• Does this mean, there is no way to update other envs?
• Could boa not use/lookup mamba from the base env, to not break mamba's correct functionality?

FYI, here's my setup:

╰─ conda config --show-sources                                                            ─╯
==> /home/maye/miniconda3/.condarc <==
channels:
  - conda-forge

==> /home/maye/.condarc <==
channel_priority: strict
report_errors: True

==> /home/maye/miniconda3/envs/py38/.condarc <==
pinned_packages:
  - jupyter_client=6
  - nbconvert=5
channels:
  - conda-forge

─ mamba --version                                                                        ─╯
mamba 0.17.0
conda 4.10.3

[wolfv]

Hi Michael,

thanks for the issue. Maybe in the future we can remove the dependency on mamba and depend on libmambapy instead -- we've just started this split in mamba and the latest commits on boa are related to that (moving to this new intermediate library).

libmambapy does not come with the mamba executable, and therefore these problems should "go away".

Regardless, I think conda, conda-build, mamba, and boa are "best installed" in the base environment. At least that's how I do it :)

The place of the (default) build outputs also corresponds to the "base" prefix (e.g. ~/miniforge3/conda-bld etc.)

[michaelaye]

Unfortunately some build tools like fastai's fastrelease rely on having mambabuild available in the current environment, at least in their default setup.

In the case of not using fastrelease, is it possible to build for different python versions using only the one set of tools in the base env? If that's possible, maybe I can ask the fastrelease guys to enable building from base as well...

[wolfv]

when you run boa / mambabuild / conda-build it is completely isolated from the "build" and "host" env of the build execution. You can use boa with python 3.7 to create a python 3.10 package of somethign else. If that is what you mean

[wolfv]

When you run the build, conda-build / boa will create environments in ROOT_RPEFIX/conda-bld/mytempbuildfolder_1231231/{_build_env, _host_env_placholder...., work} where work contains the source code and conda_build.{sh, bat} script

[michaelaye]

and then I'd use --convert to build the other versions, like shown here? https://docs.conda.io/projects/conda-build/en/latest/user-guide/tutorials/build-pkgs.html#converting-a-package-for-use-on-all-platforms

sorry for the noob-builder questions, only recently started to seriously into conda package building...

[michaelaye]

i think there's no CLI option to do the first build at a different than current environment, right?

[wolfv]

you just need to place a conda_build_config.yaml file next to your recipe, or include it using -m. This defines the build matrix, e.g.: https://github.com/conda-forge/mamba-feedstock/blob/9f9bece91d8f8c3c3c11db1326685ab4d715369f/.ci_support/linux_64_.yaml#L31-L36