mamba activate doesn't work in Powershell

[owenlamont]

I'm using mamba 0.23.3 on Windows 11 and noticed the mamba activate command doesn't work in Powershell (original or Powershell Core).

Normally I use the old Windows command prompt terminal (Miniforge prompt / Anaconda (Miniconda 3) terminal) but I wanted to use Powershell again. I launched my base conda environment in Powershell using the Anaconda Powershell Prompt (miniconda3) shortcut - implemented using the powershell_shortcut package.

I can still use conda to activate environments in Powershell but trying to use mamba activate has no effect and also gives no error. See screenshot below:

[Paradoxdruid]

Mamba documentation ( https://mamba.readthedocs.io/en/latest/user_guide/mamba.html ) says:

The only difference is that you should still use conda for activation and deactivation.

[owenlamont]

Yes I did use conda for activating and deactivating for a long time, but I believe this is still a bug. mamba activate does work in Windows command prompt and on Linux/Mac terminals. As I also mentioned typing mamba activate gives no error in PowerShell, it just doesn't activate the environment - but the old behaviour if you typed mamba activate was to give an error prompt telling the user to use conda activate and it doesn't do that in PowerShell. The manual and mambas current behaviour appear inconsistent as even mamba prompts the user to "mamba activate" a new environment when you create one.

[dmyersturnbull]

I can confirm this issue.

> mamba create -n py310 python=3.10
 . . .
> conda activate py310
> python --version
Python 3.9.13

[marc-wien]

Yes I did use conda for activating and deactivating for a long time, but I believe this is still a bug. mamba activate does work in Windows command prompt and on Linux/Mac terminals. As I also mentioned typing mamba activate gives no error in PowerShell, it just doesn't activate the environment - but the old behaviour if you typed mamba activate was to give an error prompt telling the user to use conda activate and it doesn't do that in PowerShell. The manual and mambas current behaviour appear inconsistent as even mamba prompts the user to "mamba activate" a new environment when you create one.

Agree -- the fact that it silently fails when you try "mamba activate" in PowerShell is probably the biggest issue (besides just not changing the environment from (base) -- I'd say it should print a message saying to use "conda activate" instead, if getting "mamba activate" to work in PS is infeasible

[jonashaag]

Would anyone volunteer to make a fix PR? Or just a sketch of what places in the code need to be changed.

[marc-wien]

Would anyone volunteer to make a fix PR? Or just a sketch of what places in the code need to be changed.

@jonashaag Here's a crack at what I found based on my Windows Mambaforge installation:

Versions: mamba 0.25.0 conda 4.14.0

1. Need a PowerShell-specific shortcut

Whereas "Mambaforge Prompt" contains: %windir%\system32\cmd.exe "/K" C:\Users\<snip>\mambaforge\Scripts\activate.bat C:\Users\<snip>\mambaforge

"Mambaforge PowerShell Prompt" should be something like: %windir%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\Users\<snip>\mambaforge\shell\condabin\conda-hook.ps1' ; conda activate 'C:\Users\<snip>\mambaforge' "

(This was adapted from the PowerShell Prompt shortcut that Miniconda creates)

2a. Need to adapt "shell\condabin\conda-hook.ps1"

Perhaps need to create "shell\condabin\mamba-hook.ps1"

My "conda-hook.ps1" contains:

$Env:CONDA_EXE = "C:/Users/<snip>/mambaforge\Scripts\conda.exe"
$Env:_CE_M = ""
$Env:_CE_CONDA = ""
$Env:_CONDA_ROOT = "C:/Users/<snip>/mambaforge"
$Env:_CONDA_EXE = "C:/Users/<snip>/mambaforge\Scripts\conda.exe"
$CondaModuleArgs = @{ChangePs1 = $True}
Import-Module "$Env:_CONDA_ROOT\shell\condabin\Conda.psm1" -ArgumentList $CondaModuleArgs

Remove-Variable CondaModuleArgs

Presumably would want to augment with MAMBA_EXE here...

2b. Need to adapt "shell\condabin\Conda.psm1"

Perhaps need to create "shell\condabin\Mamba.ps1"

Conda.psm1 gets referenced by conda-hook.ps1, and it is a ~300 line file

It looks like a couple key places are:

1. function Invoke-Conda() - should maybe have an Invoke-Mamba() equivalent which still routes "activate" and "deactivate" to the CONDA_EXE-based routines, but all else to some pre-defined MAMBA_EXE
2. Modifying New-Alias conda Invoke-Conda -Force under "ALIASES" near the end of the file to properly alias mamba and properly route through the subroutines

---

I don't have time to experiment right now, but I might do some more investigating when I have a chance.

Cheers, Marc

[xarthurx]

Confirm this issue.

[marc-wien]

I confirmed that my recommendations do work! (mamba activate and mamba deactivate work as expected in PowerShell with these mods)

To summarize changes:

1. Create "shell/condabin/mamba-hook.ps1". It is a copy of "conda-hook.ps1", except it adds $Env:MAMBA_EXE with corresponding path (the path is the same as the $Env:CONDA_EXE path but with "conda.exe" replaced with "mamba.exe"), and it references "Mamba.psm1" instead of "Conda.psm1" in the Import-Module line.

2. Create "shell/condabin/Mamba.psm1". It is a copy of "Conda.psm1", with three additions:

   a. Under "ALIASES" section near the bottom, add New-Alias mamba Invoke-Mamba -Force

   b. Under "CONDA WRAPPER" section in the middle, copy-paste the entirety of function Invoke-Conda(), rename the copy function Invoke-Mamba(), and change $Env:CONDA_EXE to $Env:MAMBA_EXE in the two places it appears in the function. This function uses existing helper functions for activation and deactivation, so it will actually bind mamba activate or deactivate to the corresponding conda commands for free!

   c. Under "EXPORTS" section at the end, add Invoke-Mamba to the list after Invoke-Conda (under Export-ModuleMember -Function area (mind the backticks)

3. Create a shortcut on your desktop or wherever with the following target (note, there is a hardcoded path to my conda root):

   %windir%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\Users\MyUserName\mambaforge\shell\condabin\mamba-hook.ps1' ; conda activate 'C:\Users\MyUserName\mambaforge' "

   (Reminder: I found this command in a Miniconda install)

   Double click it and try to mamba activate an environment!!!

---

I will try to take a look at where in the codebase these new files would need to be created. I am not sure how "mirroring" conda files is dealt with in mamba (i.e. how to handle if Conda.psm1 changes in the future?), and furthermore whether mambaforge itself would need modified to create the shortcut with an install? Regardless, you can make these changes to your local install (at your own risk)

-M

[marc-wien]

And for good measure, in step 3 above, it also works with PowerShell 7 if you change the complete powershell.exe path at the beginning to "C:\Program Files\PowerShell\7\pwsh.exe" (including the double-quotes)

(assuming you have 7 installed)

[marc-wien]

Last nickel: Tab completion (as defined in Conda.psm1) will require further mods to Mamba.psm1 to match the conda PowerShell behavior. With my mods, if you type conda then space then hit tab, it will cycle through valid conda commands (e.g. activate, clean, etc.) -- but it will not do the same for mamba...

Recommend inspecting Conda.psm1 to see where this could be added for mamba if someone gets to it before me

[marc-wien]

Related issues I found that this fix might close or chip away at. I won't be able to implement my fix in the codebase anytime soon.

https://github.com/mamba-org/mamba/issues/1088#issuecomment-1263436804

https://github.com/mamba-org/mamba/issues/1994#issuecomment-1271462295

CC: @wolfv @jonashaag

[ollie-bell]

Mamba documentation ( https://mamba.readthedocs.io/en/latest/user_guide/mamba.html ) says:

The only difference is that you should still use conda for activation and deactivation.

I wish it wasn't the case that this is recommended ( / I wish it was the case that mamba activate works properly)...

I often find myself accidentally typing conda <command> instead of mamba <command>, because of still having the muscle memory from being forced to use conda activate.

[carlodri]

Just my two cents: don't you need to explicitly say mamba init powershell? After saying that, conda activate works but not mamba activate as the most recent docs say. Using: mamba 1.3.1 conda 23.1.0

[Alessandro201]

3. Create a shortcut on your desktop or wherever with the following target (note, there is a hardcoded path to my conda root): %windir%\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\Users\MyUserName\mambaforge\shell\condabin\mamba-hook.ps1' ; conda activate 'C:\Users\MyUserName\mambaforge' "

I found a way to avoid creating a shortcut and let the default powershell terminal open as if it would have been open with it. You need to create a powershell profile profile.ps1 in the documents folder C:\Users\MyUserName\OneDrive\Documents\PowerShell\profile.ps1 or C:\Users\MyUserName\Documents\PowerShell\profile.ps1. If the file already exists and you find the following lines you can comment or remove them:

#region conda initialize
# !! Contents within this block are managed by 'conda init' !!
If (Test-Path "C:\Users\MyUserName\mambaforge\Scripts\conda.exe") {
    (& "C:\Users\MyUserName\mambaforge\Scripts\conda.exe" "shell.powershell" "hook") | Out-String | ?{$_} | Invoke-Expression
}
#endregion

Then add:

#region mamba initialize
# Fix to open powershell with the base mamba environment activated
If (Test-Path "~\mambaforge\shell\condabin\mamba-hook.ps1") {
    & "~\mambaforge\shell\condabin\mamba-hook.ps1" ;
    conda activate "~\mambaforge"
}
#endregion

In Powershell, ~ points to the user home directory, but if it doesn't work you can write the full path.

You can also repeat the steps for Windows Powershell by creating\modifying profile.ps1 at C:\Users\MyUserName\OneDrive\Documents\WindowsPowerShell\profile.ps1 or C:\Users\MyUserName\Documents\WindowsPowerShell\profile.ps1

[gongzhq136]

I had the same "silence" problem with Powershell. But with WindowsPowershell, conda activate still works. This strenge behavior lead me to find out that if you by chance have oh-my-posh installed and in Microsoft.PowerShell_profile.ps1 exist this line:

'oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\robbyrussell.omp.json" | Invoke-Expression'

In this case, the conda init block in profile.ps1 will be invalidated, because according to microsoft, profile.ps1 run first and then Microsoft.PowerShell_profile.ps1.

After I move the oh-my-posh init pwsh ... line prior to the conda init block, conda activate works again with Powershell. But this doesn't resolve the problem of mamba activate, which confirmly has the issue.

[timhillel]

Last nickel: Tab completion (as defined in Conda.psm1) will require further mods to Mamba.psm1 to match the conda PowerShell behavior. With my mods, if you type conda then space then hit tab, it will cycle through valid conda commands (e.g. activate, clean, etc.) -- but it will not do the same for mamba...

Recommend inspecting Conda.psm1 to see where this could be added for mamba if someone gets to it before me

Managed to get tab autocompletion working: under "TAB COMPLETION" section in Mamba.psm1, in function TabExpansion, replace two instances of ^conda with ^mamba.

To add repoquery to autocomplete, in the above function Expand-CondaSubcommands replace $ValidCommands + @('activate', 'deactivate') with $ValidCommands + @('activate', 'deactivate', 'repoquery')

I also aded a secion to my profile.ps1 file to run mamba-hook.ps1 (as per suggestion from @Alessandro201) leaving the default code to also run conda-hook.ps1. With this, the environment would appear twice, so suggest removing "PROMPT MANAGEMENT" in your Mamba.psm1 file if this happens.

EDIT: I can see there are Mamba.psm1 and mamba_hook.ps1 files in libmamba/data on the repo - I guess these issues have now been fixed in latest version?

[temeddix]

It's been a while(a few years) since Window's default terminal has changed from CMD to Powershell. Shouldn't mamba activate support Powershell without any additional configuration?

[mhvwerts]

It would indeed be nice and helpful to have transparent PowerShell support for mamba and miniforge. The current miniforge3 installer for Windows only creates a 'CMD'-type prompt in the menu, without support for PowerShell.

I was creating a fresh install of miniforge3 for use with mamba, migrating from a previous miniconda3 install. The latter does have a PowerShell prompt, and I was expecting miniforge to have a PS prompt too and work transparently with mamba as advertised.

[ahrib]

using mamba/1.5.3 conda/23.10.0: conda activate env works, mamba activate env does not

I tried both creating a shortcut and editing profile workarounds provided by @Alessandro201 but they did not work for me.

Notes that may help someone in future:

• my paths were slightly different.. I had to modify scripts to use "~\AppData\Local\mambaforge"
• list all powershell profiles by running $profile | Select-Object *
• mamba-hook.ps1 should read conda-hook.ps1
• mamba init is the command that sets up the #region conda initialize blocks in your profile

repeatable test case:

• win10 64bit on a VM, fresh install using mambaforge installer (have not tried miniforge)
• perform mamba update mamba=1.5.3 conda=23.10 (current stable versions)
• perform mamba init
• perform mamba create -n test_env -y
• perform mamba activate test_env

[bilderbuchi]

using mambaforge installer (have not tried miniforge)

As mambaforge has been deprecated in favour of miniforge, and there is a hint in the readme that mambaforge-related reports will be closed, it might be worthwhile to redo this repro with a miniforge installer. It probably won't make a difference, I guess, but will help avoid procedural issues getting in the way 😝

[mhvwerts]

it might be worthwhile to redo this repro with a miniforge installer. It probably won't make a difference, I guess, but will help avoid procedural issues getting in the way

I use miniforge, and indeed it does not make a difference. The missing PowerShell support is probably more a miniforge issue than a pure mamba issue.

I am just a simple scientific Python user, and look for simple installation procedures that I can easily share with colleagues and students, so that everyone has access to the Condaforge packages.

I understand that the latest versions of conda (and the latest versions of the Anaconda and Miniconda distributions) now use the mamba solver internally by default, probably being as fast and efficient as mamba itself for installing packages. It may therefore be worth trying just installing Miniconda (which does have Powershell support) and setting the default channel to Condaforge.

In any case, I appreciate all your efforts to keep this continuously evolving software ecosystem working. It does help us a great deal with our research work. Many thanks for that.

[xarthurx]

Can confirm here that for Miniforge, mamba activate xxx is still not working on Powershell.

[anhq-nguyen]

Can confirm here that for Miniforge, mamba activate xxx is still not working on Powershell.

I'm having the same issue with the latest Miniforge version.

[OnismV]

I'm having the same issue with the latest Miniforge.

[seanmamasde]

In case you also want to add conda/mamba to powershell profile, but instead of using the built-in init method (which is slow), you can try this out (reference). After configuring, the corresponding section in your powershell profile should look like this:

# alternative conda activation method (https://github.com/conda/conda/issues/11648#issuecomment-1541546403)
# mamba activation (https://github.com/mamba-org/mamba/issues/1717#issuecomment-1292845827)
$Env:CONDA_EXE = "C:\Users\YOURUSENAME\scoop\apps\miniconda3\current\Scripts\conda.exe"
$ENV:MAMBA_EXE = "C:\Users\YOURUSENAME\scoop\apps\miniconda3\current\Scripts\mamba.exe"  # for mamba
$Env:_CE_M = ""
$Env:_CE_CONDA = ""
$Env:_CONDA_ROOT = "C:\Users\YOURUSENAME\scoop\apps\miniconda3\current"
$Env:_CONDA_EXE = "C:\Users\YOURUSENAME\scoop\apps\miniconda3\current\Scripts\conda.exe"
$CondaModuleArgs = @{ChangePs1 = $False}
Import-Module "$Env:_CONDA_ROOT\shell\condabin\Conda.psm1" -ArgumentList $CondaModuleArgs
Import-Module "$Env:_CONDA_ROOT\shell\condabin\Mamba.psm1" -ArgumentList $CondaModuleArgs # for mamba
Remove-Variable CondaModuleArgs

the above section sort of hooks conda to powershell, but instead of using the built-in init method, you simply just put these lines into the $profile, and it does not automatically activate base environment on startup. In case you still want base activated whenever powershell starts, just put conda activate base or mamba activate base after this block. the ChangePs1 = $False in the $CondaModuleArgs can be omitted, it's just removing the environment tag before the prompt like (base) C:\Users\...>

[morning-start]

Always use the "conda" command, it will be automatically converted when executed. Need conda init first.

Usage

1. notepad "$PROFILE"
2. add bellow code in the file.

# use command conda to call mamba or conda
Set-Alias -name conda -value CondaOrMamba
function CondaOrMamba {
    param(
        [Parameter(Position = 0, Mandatory = $true)]
        [string]$Command,
        [Parameter(ValueFromRemainingArguments = $true)]
        [string[]]$Args
    )

    # list of mamba supported commands
    $mambaCommands = @("install", "create", "list", "search", "run", "info", "clean", "remove", "update", "repoquery")

    # check if the command is in the list of mamba commands
    if ($mambaCommands.Contains($Command)) {
        & mamba $Command @Args
    } else {
        # use Invoke-Conda instead of conda
        & Invoke-Conda $Command @Args
    }
}

[sun2ot]

The latest version of minifoge 24.3.0 still suffers from this problem

[Burgerd4sh]

got the same problem too

[shijunti19]

还未解决吗，不能使用