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

Using Mamba instead of Conda #185

Open
albop opened this issue Jul 8, 2020 · 14 comments
Open

Using Mamba instead of Conda #185

albop opened this issue Jul 8, 2020 · 14 comments

Comments

@albop
Copy link

albop commented Jul 8, 2020

mamba is a dropin replacement for the conda package manager, which uses the same archive format as conda. Being written in c++, it is much much faster than conda itself, which matters a lot to me given the number of time, I happen to be recreating Julia/Python environement. Given it takes the same options as conda, I suppose it could be swapped or used optionally in Conda.jl with relatively little effort.

There is also an alternative, micromamba, which might also be useful in the Julia context, since it can be used to bootstrap a conda environment with no dependence on a Python executable (for instance, to install R libraries).

@albop albop changed the title Use Mamba instead of Conda Using Mamba instead of Conda Jul 8, 2020
@stevengj
Copy link
Member

stevengj commented Jul 8, 2020

It might be possible to support this as an install-time option, but I'm reluctant to make it the default lest we introduce some incompatibilities.

(Hopefully, once Mamba fully implements conda functionality and passes the conda test-suite, Anaconda itself will adopt it if it is so much faster. I'm reluctant to get ahead of Anaconda itself here.)

@albop
Copy link
Author

albop commented Jul 8, 2020

I understand your point about introducing incompatibilities.

Having an option to do that would be great. I suppose those who opt-in would end-up with both conda and mamba installed in their environment so that it is possible to use mamba for installation (where it really shines, and possibly passes the appropriate tests?) and conda when the functionalities are missing.

@SylvainCorlay
Copy link

We recently published this blog post about mamba, and we actually included some comments on how it may be really amenable to Julia bindings.

Mamba is very actively developed, on funded time, by several people. It has been adopted at scale by conda-forge for large software migrations, and is also in use in the bioconda community. We test mamba continuously, and dogfoot it in our team - but there isn't a "golden test suite" from conda that it would make sense to run on mamba

Happy to help with any question!

@stevengj
Copy link
Member

stevengj commented Jul 10, 2020

A first step might be to package micromamba or similar on Yggdrassil — this is the most convenient way to handle binary dependencies in Julia. (Basically, we write a build script, and then Yggdrasil automatically cross-compiles binaries for all supported platforms.)

It is possible to call Mamba as a library? Ideally with C bindings, as those are the easiest to access cross-language? (It would be great to avoid spawning a process for every command.)

@anna-parker
Copy link

It would be amazing if a Mamba.jl package replacing Conda with Mamba was available. Conda is terribly slow. Any progress on this since @SylvainCorlay? Many thanks in advance!

@stevengj
Copy link
Member

stevengj commented Jun 2, 2022

Someone needs to create a Yggdrasil build script, to start with, for us to easily use this in Julia.

@isuruf
Copy link
Collaborator

isuruf commented Jun 2, 2022

You can already use mamba with Conda.jl.

julia> using Conda
julia> Conda.add("mamba")
julia> ENV["CONDA_JL_CONDA_EXE"] = joinpath(Conda.ROOTENV, "bin", "mamba")
pkg> build Conda

and then restart julia.

@isuruf
Copy link
Collaborator

isuruf commented Jun 2, 2022

If it worked, you should be able to see something like below

julia> Conda.CONDA_EXE
"/home/isuru/.julia/conda/3/bin/mamba"

@isuruf
Copy link
Collaborator

isuruf commented Jun 2, 2022

For windows, joinpath(Conda.ROOTENV, "bin", "mamba") would change slightly.

@anna-parker
Copy link

@isuruf this works amazingly! Thank you!

@frankier
Copy link

frankier commented Sep 2, 2022

JuliaPackaging/Yggdrasil#5318

@hhaensel
Copy link

hhaensel commented Sep 24, 2022

For windows, joinpath(Conda.ROOTENV, "bin", "mamba") would change slightly.

Yip, it would be

ENV["CONDA_JL_CONDA_EXE"] = joinpath(Conda.ROOTENV, "condabin", "mamba.bat")

Just tried and worked like a charm. Much shorter installation times 😄
EDIT: Not sure whether it should be joinpath(Conda.ROOTENV, "Scripts", "mamba.exe") instead ...

@deszoeke
Copy link

deszoeke commented May 15, 2023

I have started managing my python packages outside of julia with mamba. I think, then, mamba is managing environment of the shell from which I launch julia or python.

Is it possible that this outside mamba is interfering with the default conda installation used by julia?

I have hangs and crashes when, e.g., using PyPlot or pyimport("numpy"). I think it's possible that this is correlated to switching to mamba.

Do I need to reset some environment variables when building Conda (or PyCall) to make this work? I already do ENV["PYTHON"]="".

@feefladder
Copy link

I was trying things... Basically, trying to run Julia inside Python using micromamba for python deps management. When trying to install PyCall, it fails, because it uses --satisfied-skip-solve e.g. this issue. Not sure if it should be solved there or here. I think here is a better option, e.g. add a check here.

ref

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

No branches or pull requests

9 participants