runner.conda: Bump Micromamba from 1.5.8 → 2.1.0

[joverlee521]

Description of proposed changes

Newer versions since 2.0.0 include fix for installing nextstrain/conda-base when the dependencies specify x86_64-microarch-level.

Related issue(s)

Resolves #429
Related to nextstrain/conda-base#105

Checklist

• Checks pass

[victorlin]

Tested alongside nextstrain/conda-base#108.

NEXTSTRAIN_CONDA_CHANNEL=nextstrain/label/pull-108 \
NEXTSTRAIN_CONDA_BASE_PACKAGE="nextstrain-base ==20250417T231442Z" \
  ./devel/venv-run nextstrain setup --force conda

Output:

Checking setup…
✔ yes: operating system is supported
✔ yes: Rosetta 2 is enabled
✔ yes: runtime data dir doesn't have spaces
✔ yes: runtime appears set up
✔ yes: snakemake is installed and runnable
✔ yes: augur is installed and runnable
✔ yes: auspice is installed and runnable

All good!  Set up of conda complete.

[joverlee521]

I also tested locally to ensure that the nextstrain update conda command works as expected

$ NEXTSTRAIN_CONDA_CHANNEL=nextstrain/label/main \
NEXTSTRAIN_CONDA_BASE_PACKAGE="nextstrain-base ==20250226T220403Z" \
  ./bin/nextstrain setup --force conda
...
All good!  Set up of conda complete.

$ ./bin/nextstrain update conda
Checking for newer versions of Nextstrain CLI…

nextstrain-cli is up to date!

Updating conda runtime…
Updating Conda package nextstrain-base from 20250226T220403Z to 20250311T191147Z…
...
Updated conda runtime!

All updates successful!

$ NEXTSTRAIN_CONDA_CHANNEL=nextstrain/label/pull-108 \
NEXTSTRAIN_CONDA_BASE_PACKAGE="nextstrain-base ==20250417T231442Z" \
  ./bin/nextstrain update conda
Checking for newer versions of Nextstrain CLI…

nextstrain-cli is up to date!

Updating conda runtime…
Updating nextstrain-base from 20250311T191147Z to ==20250417T231442Z…
...
Updated conda runtime!

All updates successful!

[tsibley]

What's the story for existing users here?

If I understand correctly, they're going to run into errors during nextstrain update conda with the newer nextstrain-base packages due to _x86_64-microarch-level being present in transitive deps and the Micromamba bug in 1.5.8. Their resolution for those errors with this PR as-is would be to 1) upgrade Nextstrain CLI to get this PR's changes and then 2) manually force a new setup with nextstrain setup --force conda to get the new Micromamba version. Is that correct?

That feels somewhat crummy. I wonder if we can make it better. Some (very different) potential options I'd see are

1. Automatically update Micromamba during nextstrain update if applicable. That reduces a user's steps to resolution to just upgrading Nextstrain CLI, upon which nextstrain update works again (no force setup needed).

2. Build nextstrain-base for _x86_64-microarch-level ==1 (which we might we want to do anyway) and completely avoid the errors and need for any resolution, since that level was not affected by the bug (i.e. __archspec 1 x86_64 is correctly handled by Micromamba even on 1.5.8). The downside is some programs will be slower than they could be because they won't be compiled to take advantage of processor features.

3. Some combination of the two + building nextstrain-base for multiple _x86_64-microarch-levels such that old CLIs/setups keep getting updates but that aren't as fast as they could be while newer CLIs/setups reap the benefits.

Maybe y'all see other options?

[joverlee521]

Their resolution for those errors with this PR as-is would be to 1) upgrade Nextstrain CLI to get this PR's changes and then 2) manually force a new setup with nextstrain setup --force conda to get the new Micromamba version. Is that correct?

Yeah, this was my expected resolution for existing users. I didn't think 2 commands to resolve the issue would be too bad...

Option (2) seems to work (nextstrain/conda-base#111), so I'd be inclined to go with that for now and revisit option (3) in the future if needed.

[tsibley]

+1 for option (2) for now and (3) not "if needed" but soon to follow. By the time we're doing (3), we'd want to have already done this Micromamba version bump. I'd also like to include logic with it to update Micromamba during nextstrain update. (This may interact with my WIP for a better update story for #379 too; need to get back to that.)

I didn't think 2 commands to resolve the issue would be too bad...

It's not that two commands themselves would be too onerous, but that the way folks will encounter the issue is that suddenly nextstrain update will no longer work with an inscrutable error. The only way they'll know the correct resolution is to come ask for help somewhere and now they're blocked. As a bonus, if they think to force-re-setup themselves without also upgrading Nextstrain CLI, they're going to end up with no working Conda runtime at all. I believe strongly in the (often understated!) power of software that Just Keeps Working and especially so when it comes to the update process (because you want folks to feel comfortable upgrading). This sort of compatibility error is different than a bug, in my view. There's a huge loss-of-confidence difference between, "Ah, drat, I tried something I haven't done before and it didn't work/I hit a bug" vs. "It was working and I did something I've done before (updating) and now it's not working."

[tsibley]

The issue this change was intended to help resolve was instead resolved without needing any updates to Nextstrain CLI itself.

We should still bump Micromamba at some point, but it is no longer urgent. I would like to block bumping it on smoothing the upgrade process for existing runtime setups (as I described above). The work I did for upgrading/switching the Conda subdir used by the runtime (e.g. osx-64 → osx-arm64) laid a nice trail for similarly upgrading Micromamba versions as well. The difference is that the whole runtime env doesn't need re-setup, just Micromamba.

Marking this as draft for now.