Summary
Switching the default Conda build template to conda/micromamba:v2 (#1024) exposed a compatibility issue with Conda packages that rely on activate.d scripts.
The v2 template builds the Conda environment in one stage and copies it into a clean final image. Unlike the previous template, the final image does not run micromamba activate, so the environment variables configured by activate.d scripts are not loaded.
This affects packages such as cmdstan, which uses an activation script to set CMDSTAN, as well as compiler packages that set variables such as CC and CXX. Since v2 is now the silent default for all Conda-based builds, any package relying on this mechanism is currently affected, with no warning.
This also isn't purely new to v2: singularity exec (what Nextflow uses to run Singularity tasks) never runs a Docker image's ENTRYPOINT, so the previous (v1) template's Singularity output had the same gap all along. v1's Docker output only worked by accident, because it inherited mambaorg/micromamba's own activation entrypoint.
Fix
#1118 combines the installed activate.d scripts into a single script during the build, then loads it via BASH_ENV in the final image (Docker ENV, Singularity %environment), with nounset temporarily disabled while loading since some activation scripts reference variables that aren't defined until then.
BASH_ENV is a static image property rather than a runtime entrypoint, so it's honored by both docker run and singularity exec/apptainer exec.
Summary
Switching the default Conda build template to
conda/micromamba:v2(#1024) exposed a compatibility issue with Conda packages that rely onactivate.dscripts.The v2 template builds the Conda environment in one stage and copies it into a clean final image. Unlike the previous template, the final image does not run
micromamba activate, so the environment variables configured byactivate.dscripts are not loaded.This affects packages such as
cmdstan, which uses an activation script to setCMDSTAN, as well as compiler packages that set variables such asCCandCXX. Since v2 is now the silent default for all Conda-based builds, any package relying on this mechanism is currently affected, with no warning.This also isn't purely new to v2:
singularity exec(what Nextflow uses to run Singularity tasks) never runs a Docker image'sENTRYPOINT, so the previous (v1) template's Singularity output had the same gap all along. v1's Docker output only worked by accident, because it inheritedmambaorg/micromamba's own activation entrypoint.Fix
#1118 combines the installed
activate.dscripts into a single script during the build, then loads it viaBASH_ENVin the final image (DockerENV, Singularity%environment), withnounsettemporarily disabled while loading since some activation scripts reference variables that aren't defined until then.BASH_ENVis a static image property rather than a runtime entrypoint, so it's honored by bothdocker runandsingularity exec/apptainer exec.