Add support for micromamba environments

[CarlAndersson]

Type: Bug

Behaviour

Expected vs. Actual

I expect the python: conda path setting to be used everywhere conda is called.
As can be seen from the logs, a plain conda call is used many times, and something tries to find python installations under ~\Miniconda3\..., which does not exist.
This results in that no environments are found, and pylance cannot find locally installed packages.

Steps to reproduce:

1. Uninstall conda if you have it.
2. Install micromamba
3. Set the conda path to point to micromamba

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.11.0
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
• Value of the python.languageServer setting: Pylance

Output for Python in the Output panel

User Settings

condaPath: "C:\Users\carl4189\micromamba\condabin\micromamba.bat"

languageServer: "Pylance"

linting
• flake8Args: "<placeholder>"
• flake8Enabled: true
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: true
• pydocstyleEnabled: true

terminal
• activateEnvironment: false

Extension version: 2023.5.10791008
VS Code version: Code 1.76.2 (ee2b180d582a7f601fa6ecfdad8d9fd269ab1884, 2023-03-14T17:55:54.936Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (8 x 2112)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	15.78GB (6.73GB free)
Process Argv
Screen Reader	no
VM	0%

[karrtikr]

Thanks for the bug report! We just wanted to quickly acknowledge we received it and we will triage this as soon as we can.

[psobolewskiPhD]

Would love to see this work. Mamba works, because conda is still present. But micromamba doesn't have a base env with conda.

[karrtikr]

Turning this into a feature request as we currently don't support micromamba, to resolve this we need to support identifying micromamba version correctly.

Currently if version is below 4.7, we do not use conda/micromamba run, so environment is not activated before it is used leading to import errors.

[github-actions]

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

[CarlAndersson]

micromamba run exists at least in micromamba version 1.0.0. The changelog indicates that is has existed since version 0.21.0.
The output from conda info --json and micromamba info --json might be a good place to find out if the command is conda or mircomamba without resorting to inspecting the command name. E.g., conda info --json has a 'conda_version', while micromamba info --json has a 'micromamba version'.
Let me know if there's anything more I can do to assist!

[brettcannon]

Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.

[karrtikr]

Basic support

• Add support for correctly identifying version for micromamba
• Make sure micromamba envs are automatically discovered
• Add micromamba run support
• Add ability to support adding custom path to micromamba

[allefeld]

As a workaround: Create a file activate in ~/.local/bin/ or wherever micromamba is installed. Put the text micromamba activate -p into it.

I would still very much appreciate if Micromamba were supported out of the box.

[hadim]

It would be nice to support pixi as well: https://github.com/prefix-dev/pixi

[richarddwang]

As a workaround: Create a file activate in ~/.local/bin/ or wherever micromamba is installed. Put the text micromamba activate -p into it.

I would still very much appreciate if Micromamba were supported out of the box.

Didn't find it works, my current workaround is to set alias conda=micromamba at the end of bashrc or bashprofile. This is currently the only way for me to open a new terminal and get the selected micromamba environment automatically activated.

But still sometimes in notebooks, Pylance can not recognize environment for vscode intelligent after some period of time but the code can be properly run, I have to reload window every time I encountered this.

[392781]

As a workaround: Create a file activate in ~/.local/bin/ or wherever micromamba is installed. Put the text micromamba activate -p into it.
I would still very much appreciate if Micromamba were supported out of the box.

Didn't find it works, my current workaround is to set alias conda=micromamba at the end of bashrc or bashprofile. This is currently the only way for me to open a new terminal and get the selected micromamba environment automatically activated.

But still sometimes in notebooks, Pylance can not recognize environment for vscode intelligent after some period of time but the code can be properly run, I have to reload window every time I encountered this.

So to actually get around this for bash without editing your .bashrc, the file ~/.local/bin/activate should have the following line: micromamba activate $1

This way, source .../.local/bin/activate /path/to/env will take the path portion as the first argument.

To recap:

1. In Settings -> Python: Conda Path, set your micromamba executable location (in standard cases should be ~/.local/bin/micromamba
2. Create a file in ~/.local/bin/ called activate. Have the file contain micromamba activate $1.

This should provide a workaround/painless fix to the issue while VSCode devs sort this out more thoroughly.

[richarddwang]

Hi, thanks for the alternatives.

Test it on MacOS only but when I open a new terminal,
VScode automatically inputed source activate, and report source: no such file or directory: activate
and then VSCode tried conda activate ~/micromamba/envs/dev and reported zsh: command not found: conda.
It seems that VSCode doesn't use ~/.local/micromamba/activate that we created, nor notice the conda path we set.

So for others, if you failed at the aforementioned method, setting alias conda='micromamba' might be the ok option for you.

[392781]

@richarddwang I should've specified that this is a fix on Linux using bash shell.

[branchus]

Hi, thanks for the alternatives.

Test it on MacOS only but when I open a new terminal, VScode automatically inputed source activate, and report source: no such file or directory: activate and then VSCode tried conda activate ~/micromamba/envs/dev and reported zsh: command not found: conda. It seems that VSCode doesn't use ~/.local/micromamba/activate that we created, nor notice the conda path we set.

So for others, if you failed at the aforementioned method, setting alias conda='micromamba' might be the ok option for you.

Thank you for this the walkaround.
Hope VSCode officially support micromamba soon

by the way if you are under windows and using PowerShell, you can add below line to the PS profile

Set-Alias -name conda -value micromamba

Dose the same thing, set alias for micromamba

[brettcannon]

I will say we are aware that people want ways to have tools contribute to providing environments and interpreters, and we are thinking about a solution around this so extensions like https://marketplace.visualstudio.com/items?itemName=corker.vscode-micromamba could supply interpreter information. There is no ETA on that work, though, as we are tied up with other work for the foreseeable future.

[392781]

I will say we are aware that people want ways to have tools contribute to providing environments and interpreters, and we are thinking about a solution around this so extensions like https://marketplace.visualstudio.com/items?itemName=corker.vscode-micromamba could supply interpreter information. There is no ETA on that work, though, as we are tied up with other work for the foreseeable future.

But wouldn't implementing this be rather straightforward? It already works with Anaconda which is a gargantuan toolset in comparison to micromamba (which relies on a single binary). In addition, micromamba (and mamba for that matter) are drop-ins for Anaconda. Anything Anaconda does, (micro)mamba does the same.

There is already seems to be sufficient overlap if hacking together a solution works without the use of extensions...

[brettcannon]

But wouldn't implementing this be rather straightforward?

I realize it looks like it, but we are also talking about participating in our "Create Environment" command, etc., so it isn't as simple as it might look at first glance.

There is already seems to be sufficient overlap if hacking together a solution works without the use of extensions...

We would prefer not to use a hack to support (micro)mamaba and instead move everything (including Anaconda) to the new model for better, more thorough support and increase our test matrix (I realize mamba is meant to be a drop-in replacement, but if anything deviates we will be expected to support it, rightfully or not; for instance, micromamba's run command at least used to deviate from conda).

[wpbonelli]

Maybe I am wrong but relying on possibly 3rd-party extensions for interpreter information seems at least as risky as expecting micromamba to conform to conda conventions. Or do MS intend to own the extensions for each supported interpreter?

Would a (well-tested) "hack" from an external contributor be accepted in the interim, given there is no timeline on the long-term solution?

[brettcannon]

Maybe I am wrong but relying on possibly 3rd-party extensions for interpreter information seems at least as risky as expecting micromamba to conform to conda conventions. Or do MS intend to own the extensions for each supported interpreter?

I would rather not get into a design discussion here on the topic and wait until we open an issue on a proposed design.

Would a (well-tested) "hack" from an external contributor be accepted in the interim, given there is no timeline on the long-term solution?

We will have to think about it. We're discussing plans for 2024 right now, so depending how long we think things might take we could consider adding mamba and micromamba support with the caveat that it will probably move out.

[YouJiacheng]

{
    "python.venvPath": "<MAMBA_ROOT_PREFIX>/envs"
}

can help vscode-python find environments. (I just found it out today).

python.condaPath doesn't work at all. Command-based activation doesn't use it either. "Path to the conda executable to use for activation (version 4.4+)." is like a joke.

For activation, I use profile as follows:

Set-Alias -Name conda -Value micromamba
function activate {
    (& $Env:MAMBA_EXE 'shell' 'hook' -s 'powershell' -p $Env:MAMBA_ROOT_PREFIX) | Out-String | Invoke-Expression
}
#region mamba initialize
# !! Contents within this block are managed by 'mamba shell init' !!
$Env:MAMBA_ROOT_PREFIX = "<MAMBA_ROOT_PREFIX>"
$Env:MAMBA_EXE = "<MAMBA_EXE>"
#(& $Env:MAMBA_EXE 'shell' 'hook' -s 'powershell' -p $Env:MAMBA_ROOT_PREFIX) | Out-String | Invoke-Expression
#endregion

[brettcannon]

python.condaPath doesn't work at all.

@YouJiacheng would you mind opening a bug for that?

[aretrace]

I would like to express support for this!

[jan-david-fischbach]

Hey All, I cannot get this to work :/ Either the python extension complains that Active interpreter type is detected as Unknown or I run into the issue, that it complains (in the extension logs):

'micromamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To initialize the current bash shell, run:
    $ eval "$(micromamba shell hook --shell bash)"
and then activate or deactivate with:
    $ micromamba activate
To automatically initialize all future (bash) shells, run:
    $ micromamba shell init --shell bash --root-prefix=~/micromamba
If your shell was already initialized, reinitialize your shell with:
    $ micromamba shell reinit --shell bash
Otherwise, this may be an issue. In the meantime you can run commands. See:
    $ micromamba run --help

Supported shells are {bash, zsh, csh, xonsh, cmd.exe, powershell, fish}.
critical libmamba Shell not initialized

even though it is initialized and works flawlessly in interactive shell sessions.
As a result the environment does not activate when a new terminal is spawned.

It works to run python files though, as the interpreter path is used directly.

Regards JD

[stessaris]

On unix based systems I'm using direnv with this direnv vscode extension. It has the advantage that works with any backend, e.g. nix, or more complex setups; e.g., in some projects I layer a conda environment on top of a nix shell. I guess that it should work with Windows as well, but I never tried it.

To use micromamba you could modify the default anaconda layout by changing the command "$conda" shell.bash activate "$env_loc" to "${MAMBA}" shell activate -s bash -p "${env_loc}" in the eval command.

In alternative, you can use your own shell script. E.g. I use something like this (it'd be better refactored into a function, though):

MAMBA="$(command -v micromamba)"
JQ="$(command -v gojq || command -v jq)"

CONDA_ENV_NAME=lab
CONDA_ENV_YAML="${PWD}/environment.yml"

env_loc="$("$MAMBA" env list  --json|"$JQ" -r --arg en ${CONDA_ENV_NAME} '.envs[]|select(endswith("/" + $en))')"

if [ ! -d "${env_loc}" ]; then
    "${MAMBA}" env create --yes -n ${CONDA_ENV_NAME} -f "${CONDA_ENV_YAML}"
    env_loc="$("$MAMBA" env list  --json|"$JQ" -r --arg en ${CONDA_ENV_NAME} '.envs[]|select(endswith("/" + $en))')"
fi

eval "$("${MAMBA}" shell activate -s bash -p "${env_loc}")"

[specter119]

Basic support

• Add support for correctly identifying version for micromamba
• Make sure micromamba envs are automatically discovered
• Add micromamba run support
• Add ability to support adding custom path to micromamba

@kartikrajjj any update now?

[Misaka-No-10032]

I figured it out in this way:

1. Create a file named activate in the same folder as your micromamba executable.
2. Paste the following content into the file (replace with the MAMBA_ROOT_PREFIX on your machine):

#!/bin/sh
_MAMBA_ROOT="<YOUR MAMBA_ROOT_PREFIX>"
# Copyright (C) 2012 Anaconda, Inc
# SPDX-License-Identifier: BSD-3-Clause
\. "$_MAMBA_ROOT/etc/profile.d/micromamba.sh" || return $?
micromamba activate "$@"

3. Add execute permission to the file.
4. In VS Code, open settings and find python.condaPath, set the value to the path of your micromamba executable.
5. Set python.venvPath to <YOUR MAMBA_ROOT_PREFIX>/envs/

With these steps, VS Code should be able to identify and activate micromamba environments.

Note that micromamba run won't work with the Python extension because the extension checks the availability of conda run based on the conda version (conda info). Since our micromamba executable replaces conda, micromamba info returns the version 1.5.8. As a result, conda <= 4.12.x does not support conda run. Therefore, the extension assumes that conda run is not available.

[suimong]

Here's my workaround: https://github.com/suimong/micromamba-vscode-compat

Looking at the source code, I believe the key incompability between micromamba and conda that this extension cares about is the output from conda info --json. the keys of the output json from micromamba info --json is completely different from conda info --json, therefore it is impossible for vscode-python to extract any information from that json output. The solution is a making a shell script as the micromamba wrapper, which modifies the keys of micromamba info --json before sending to stdout.

After this pr lands, micromamba will be able to output conda compatible info --json and vscode should be trivially able to support micromamba.

[Misaka-No-10032]

Here's my workaround: https://github.com/suimong/micromamba-vscode-compat

Looking at the source code, I believe the key incompability between micromamba and conda that this extension cares about is the output from conda info --json. the keys of the output json from micromamba info --json is completely different from conda info --json, therefore it is impossible for vscode-python to extract any information from that json output. The solution is a making a shell script as the micromamba wrapper, which modifies the keys of micromamba info --json before sending to stdout.

After this pr lands, micromamba will be able to output conda compatible info --json and vscode should be trivially able to support micromamba.

You are right. I found a similar solution at https://github.com/jonashaag/micromamba-pycharm, but this one is implemented in Python.

[specter119]

@karthiknadig can add somebody follow this issue?

the behavior of micromamba is quite similar with conda currently.

[brettcannon]

We actively rewriting our discovery code (driven by @DonJayamanne ) as well as working towards an API to make so people can create an e.g. micromamba extension that feeds interpreter info to the extension (being driven by @karthiknadig ). There's no ETA on any of this, but do know that micromamba support will be possible at some point.

[liushapku]

I figured it out in this way:

1. Create a file named activate in the same folder as your micromamba executable.
2. Paste the following content into the file (replace with the MAMBA_ROOT_PREFIX on your machine):

#!/bin/sh
_MAMBA_ROOT="<YOUR MAMBA_ROOT_PREFIX>"
# Copyright (C) 2012 Anaconda, Inc
# SPDX-License-Identifier: BSD-3-Clause
\. "$_MAMBA_ROOT/etc/profile.d/micromamba.sh" || return $?
micromamba activate "$@"

3. Add execute permission to the file.
4. In VS Code, open settings and find python.condaPath, set the value to the path of your micromamba executable.
5. Set python.venvPath to <YOUR MAMBA_ROOT_PREFIX>/envs/

With these steps, VS Code should be able to identify and activate micromamba environments.

Note that micromamba run won't work with the Python extension because the extension checks the availability of conda run based on the conda version (conda info). Since our micromamba executable replaces conda, micromamba info returns the version 1.5.8. As a result, conda <= 4.12.x does not support conda run. Therefore, the extension assumes that conda run is not available.

I confirmed this method works with the following change to the activate file:

_MAMBA_EXEC=/path/to/micromamba/executable
_MAMBA_ROOT="$HOME/micromamba"
__mamba_setup="$(_MAMBA_EXEC --shell ${SHELL##*/} --root-prefix "${_MAMBA_ROOT}" 2> /dev/null)" || echo "activation failed" > $LOG
eval "$__mamba_setup"
micromamba activate "$@"

1. I simply downloaded an micromamba executable and put it in one of the PATH. No etc/profile.d/micromamba.sh ever existed.
2. The . should not be escaped to represent source
3. the file activate should be put in the same dir as the executable. (Maybe It is also recommended to add deactivate)
4. ${SHELL} is usually the full path like /usr/bin/bash, but micromamba only accepts bash.
5. If fail to activate, check the LOG

[YouJiacheng]

Hey guys! I think we can just switch from micromamba to pixi.
I think pixi is a better micromamba, and it has been supported by vscode-python since 9 Jul 2024!
https://github.com/microsoft/vscode-python/releases/tag/v2024.10.0
#22968

Why pixi: https://prefix.dev/blog/pixi_a_fast_conda_alternative

• Faster
  
• NO Activation Needed!
• Native Support for Globally Installed tools -- NO base Environment Needed!
  • Each globally installed tool lives in its own isolated environment
• Better PyPI dependencies Integration (uv!)

Transitioning Guide: https://pixi.sh/latest/switching_from/conda/