Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating to mamba 2.0.5 breaks the default Miniforge installation in Windows #3727

Open
alex180500 opened this issue Jan 5, 2025 · 6 comments
Labels
where::windows Windows-specific issues

Comments

@alex180500
Copy link

alex180500 commented Jan 5, 2025

As mentioned here conda-forge/miniforge#703 updating the latest miniforge version (which is the recommended way to install mamba) breaks the base environment and other stuff.

400020941-5def7be7-1875-479c-afe4-a15d51374835

Steps to reproduce:

  1. Fresh install of 24.11.0 Miniforge for windows (ships with mamba 1.5.12)
  2. mamba update --all on the base environment from miniforge shell
@jjerphan
Copy link
Member

jjerphan commented Jan 6, 2025

Do you mean that your environment list is not shown?

@alex180500
Copy link
Author

There are multiple problems (as listed here conda-forge/miniforge#703):

  1. The environment list is broken as it shows a blank active environment and a base environment although I should only have the base environment active.
    image
  2. Updating with mamba update on the base environment emits a line of gibberish that is sent to powershell
    image
  3. mamba shell init powershell should rewrite older mamba init in the powershell profiles

@jjerphan jjerphan added the where::windows Windows-specific issues label Jan 6, 2025
@kuepe-sl
Copy link

kuepe-sl commented Jan 7, 2025

The "glibberish" is caused by mamba update mamba modifying the condabin\mamba.bat file during the update. (changes see 651622b#diff-c62908c4dda4e1447bacf6739e9d7e22210cfd907b9ce81019b95726196dfde9)
After the update, cmd.exe tries to resume executing the .bat file and due to the changed content it tries to execute random text.

To make things worse, the errors cause a return code of 1 and thus any Mamba update from 1.x to 2.x in a CI system will fail.

@Klaim
Copy link
Member

Klaim commented Jan 7, 2025

These changes are necessary for shell init to work correctly (in the case of cmd), however we didnt consider that an update command would be able to, as part of it's applied modifications, run that shell init, which (now obviously) happens when the package is mamba itself...
Looking for a solution 👍🏽 Right now updating mamba that way was silently broken because it assumed that shell scripts never change.

@jjerphan
Copy link
Member

@kuepe-sl and @alex180500: would you be free for a call in the coming days so that we can better understand your setup the problems you are having?

@alex180500
Copy link
Author

alex180500 commented Jan 10, 2025

I'm not available for calls in this period but the steps to reproduce are:

  1. Fresh install of 24.11.2-1 Miniforge for windows (ships with mamba 1.5.12) downloading Miniforge3-24.11.2-1-Windows-x86_64.exe. Simple default installation.
  2. From Miniforge prompt mamba update --all (which updates mamba from 1.5.12 to 2.0.5) then yes

Just after these steps:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
where::windows Windows-specific issues
Projects
None yet
Development

No branches or pull requests

4 participants