Open gernophil opened 3 weeks ago
That's a mamba
issue. You won't have that issue with the upcoming one v2, but there's nothing we can do from Miniforge for now. That said, both mamba and conda+conda-libmamba-solver should be pretty much equivalent for new environments.
Thanks for the answer. So, do I get you correct that the mamba team is already aware of that and there's no need to file a bug report there?
That said, I still have the impression that mamba is faster then the conda+conda-libmamba-solver. It definitely looks nicer :). I still prefer it.
I don't know if they'll patch the 1.x releases so the mamba env create
endpoint is also monkeypatched. But what I can tell you is that the v2 release doesn't rely on conda at all (think of mamba
as a dynamically linked micromamba
), as it's C++. So when that's included in this release, you'll just use mamba create --file
.
If you'd like to drop your impressions of the performance differences in the conda-libmamba-solver repo, I'd be happy to take a look, but yea, there are a few things we can't avoid in the conda
CLI for now.
Solution to issue cannot be found in the documentation.
Issue
Not sure, of this is a
miniforge
ormamba
issue: If I generate an environment usingmamba create -n test python
it generates and environment using the mamba solver from the mamba package (this is the desired outcome):However, if I create an environment from a yaml file using
mamba env create -f test.yaml
using this yaml file:it seems like the libmamba solver from the conda package is used:
How can I get mamba env create to use the mamba solver from the mamba package?
Installed packages
Environment info