Reimplement: mamba env create -f env.yml
Currently:
mamba env create -f env.yml
falls back to conda. We could reimplement it with:
mamba create -n env_name packages_in_env.yml -c channels_in_env.yml
by parsing the YAML file. What do you think?
the issue I can see is that this behavior does not match conda which (afaik) doesn't implement YAML environments under the conda create command.
What I mean is that whatever the file specified after -f is, we get the package name, packages and channels, and use them in mamba create. It should be the same behavior, right?
I almost exclusively create envs via conda env create -f foo.yaml
Will mamba provide its functionality for this use case anytime soon?
@vv111y we have the same command. It's just only the solving that is done inside mamba, everything else is done by conda in this case.
Also, we're working towards better command line interfaces in micromamba.
okay so we will see some acceleration?
ADD: just tried it for one case and yes that was much quicker. If this is the typical performance then it definitely makes a difference - Thank you.
It would still be ideal to create directly from a file, but one alternative is to update an existing env:
mamba env update -n <your-env> --file environment.yml
Thanks @akaszynski for the solution, creating an empty environment with the right name then using mamba to update it from the environment.yml worked like a charm.
Isn't it already working as intended? I've just created a new environment running mamba env create -f env.yml with mamba from latest minimamba release...
It uses mamba to solve, but conda to download and install the packages.
Sorry, but if updating an env works (with mamba env update -n foo -f foo.yml), what exactly is missing for mamba env create -f foo.yml to be fully implemented in mamba? Most of the relevant code (e.g. parsing yml files, mentioned in the first post) should already be in place for env update to work, right?
Unless mamba env update also uses conda for the actual download and installation?
Just in case it's helpful for someone: I made a gist with a Powershell script which combines the conda env create and mamba env update commands.
If the script from the gist is in your PATH you can do: mamba_create.ps1 .\environment.yml
It would still be ideal to create directly from a file, but one alternative is to
updatean existing env:mamba env update -n <your-env> --file environment.yml
I tried this approach, but I'm facing an issue when mamba is NOT installed in the base environment. These are my commands:
conda create -n my_env -c conda-forge python=3.9 mamba
conda activate my_env
mamba env update -n my_env --file environment.yml
I expect the environment my_env to be updated with all packages, instead it creates a new environment within the environment:
my_env * /opt/conda/envs/my_env
/opt/conda/envs/my_env/envs/my_env
This is also a problem for the reason that my_env/my_env cannot be activated from normal conda.
How can I use an environment.yml file with mamba OUTSIDE the base environment?
When creating a VM with JupyterLab on the Google Cloud Platform, the conda base environment is already full with packages. Trying to install Mamba here results in an over 2 hour wait with the following output:
(base) $ conda install mamba -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: -
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
Examining XXX: XX%|████████
Examining conflict for dataclasses pyopenssl conda jinja2-time notebook debugpy nb_conda_kernels
# still ongoing after 2 hours, so I stopped here
Therefore, installing mamba in (base) env is not an option for my use-case.
I would like to use Mamba to replace Conda as my environment manager, but not having the option to use an environment.yml file is a significant drawback
???
@nelsoncardenas I installed mambaforge, where mamba is the default package manager, but it still also includes conda. In fact I'm not aware of any way of installing mamba that won't also give you conda along with it. (Edit: maybe micromamba, but to me that's a separate thing from mamba anyway.)
Personally, I use mamba for everything except those few things that still don't work. That's probably also why they still pack conda with it..
@NumesSanguis:
When creating a VM with JupyterLab on the Google Cloud Platform, the conda base environment is already full with packages. Trying to install Mamba here results in an over 2 hour wait with the following output:
Can you try with:
conda install --freeze-installed -c conda-forge mamba
This should avoid updating/downgrading existing packages and just give you compatible mamba version (if there is such version).
conda install --freeze-installed -c conda-forge mamba
@janxkoci Currently not on a project that this is needed, but will let you know once I've been able to test that.
Sorry, I'm a new user and English is not my native language, so I can miss understand the situation. I was having problems when I was trying to create an environment because it took a lot of time.
My solution was to uninstall mamba and conda and install again conda, but I changed the default solver to be based on mamba.
Extremely non-obvious that mamba env create falls back to conda... not even using libmamba solver. I am now using mamba env create -f env.yml --solver=libmamba to get around conda being killed.
As of mamba 2.0, mamba does not depend on conda anymore, and this issue must have been resolved.
mamba env create -n env_name -f env_specification.yml
can be used.