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

Deprecate the support for Mamba/Micromamba #4464

Open
pditommaso opened this issue Oct 31, 2023 · 3 comments
Open

Deprecate the support for Mamba/Micromamba #4464

pditommaso opened this issue Oct 31, 2023 · 3 comments

Comments

@pditommaso
Copy link
Member

Nextflow provides built-in support for Conda package manager to setup the task environment.

However, Conda can be considerably slow in resolving the package dependencies, for this reason alternative tools such as mamba and micromamba have been emerged to provide a faster resolution.

Nextflow supports also those tools, however this adds extra complexity in the underlying implementation.

Considering that now Conda does support the use of libmamba directly for the package resolution, this ticker aims to deprecate the direct support for Mamba and Micromamba in Nextflow considering this capability can be enabled by the user in the Conda toolset.

See here for more details https://www.anaconda.com/blog/a-faster-conda-for-a-growing-community

@pditommaso pditommaso changed the title Deprecated the support for Mamba/Micromamba Deprecate the support for Mamba/Micromamba Dec 2, 2023
@shenker
Copy link

shenker commented Jun 11, 2024

Just want to cast my vote against dropping mamba/micromamba support (at least for the time being), since mamba/micromamba (both using libmamba's locking infrastructure) allow parallel environment creation, whereas you currently get pkg cache corruption errors using conda (see conda/conda#13037). Conda has had github issues requesting this feature for years and currently I see no indications it's coming any time soon. Since micromamba support is currently broken but easily fixed with #4302, I would additionally suggest that you consider merging that PR.

It's easy to run into this problem (launch two pipelines on the same machine that both involve conda environment creation as the first step; it'll work if useMicromamba or useMamba is enabled but fail if conda is used) and quite tricky to diagnose (googling the CondaVerificationError message doesn't turn up anything useful).

#4253 solves this problem within a single nextflow (unix) process but if you're running multiple nextflow (unix) processes (e.g., as is common on academic HPC), you'll risk running into this issue.

@tbugfinder
Copy link
Contributor

Maybe also consider that the mamba license is "better" in some cases.

@bwlang
Copy link

bwlang commented Dec 25, 2024

in my hands micromamba is still much faster than conda even with libmamba. Maybe it's worth adding some timing to a test of both with installation of e.g. multiqc to see when micromamba can be dropped with little performance impact?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants