perf: update to latest miniforge, since mambaforge is deprecated and miniforge nowadays contains both mamba and conda

[johanneskoester]

No description provided.

[mbargull]

It seems like the task runs the installer with -u:

EMCP-config/ansible/roles/mambaforge/tasks/mambaforge.yml

Lines 31 to 35 in 97636d7

	- /tmp/mambaforge.sh
	- -b
	- -u
	- -p
	- "{{ mamba_home }}"

IIRC, the "update" functionality of (Conda-)constructor-created installers is not very sophisticated and does not uninstall previously installed packages, i.e., the environment is not very "clean" afterwards.

With an update from Miniforge <24.5 we'd, e.g., end up with 2 different python installs since we updated python to 3.12 in Miniforge 24.5.0.

This is at least how I remember things (haven't looked into constructor for a long time).
So, you definitely want to make sure to test this out on one/a couple of nodes before rolling it out generally.

If it indeed works as pictured above, we may want to change that task's step to always do a clean install via something along the lines of

if [ -e '{{ mamba_home }}' ]; then
  mv '{{ mamba_home }}' '{{ mamba_home }}'.old
  if ! { /tmp/mambaforge.sh -bp '{{ mamba_home }}' && '{{ mamba_home }}/condabin/conda' --version | grep -F '{{ mambaforge_conda_version }}'; }; then
    if [ -e '{{ mamba_home }}' ]; then
        mv '{{ mamba_home }}' '{{ mamba_home }}'.deleteme
        rm -rf '{{ mamba_home }}'.deleteme
    fi
    mv '{{ mamba_home }}'.old '{{ mamba_home }}'
    exit 1
  else
    rm -rf '{{ mamba_home }}'.old
  fi
else
  /tmp/mambaforge.sh -bp '{{ mamba_home }}' 
fi

(N.B.: The above is untested/just quickly written down and might not be without fault (e.g., using trap would be cleaner).)

[enasca]

Following Marcel's comment, I've added a commit which deletes the current installation if it's different from the version being installed. It doesn't implement the revert logic from the suggested script, but it takes into account that Ansible stops on failure, leaving cleanup to the user in case of a failure in the middle of the run. I think it's enough for normal operation, but it can be expanded if needed.

[enasca]

I've replied to the comments but I'm afraid I can't make changes right now. I can come back to this later tonight. In the meantime @mbargull feel free to make any changes without my approval.

[enasca]

@mbargull I've added a commit taking your feedback into account. From your table above, I'm handling the "matches" and "differs" cases explicitly. The "unknown" case is handled implicitly by the installer given that it fails if the installation directory already exists.

[enasca]

If the logic looks ok to you, Johannes can go ahead and test it.

[mbargull]

This has been deployed to almost all nodes.
Thanks everyone!