-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
CI Create environment with conda rather than conda-lock when possible #29176
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
Conversation
…and libmamba is the default solver since 23.10.10
…forge and libmamba is the default solver since 23.10.10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
MINIFORGE_PATH=$HOME/miniforge3 | ||
bash ./miniconda.sh -b -p $MINIFORGE_PATH | ||
source $MINIFORGE_PATH/etc/profile.d/conda.sh | ||
conda activate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for CI, micromamba is a lot smaller and quite fast. Would it be okay to use it or you rather not bother?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seem to remember that you had issues with updating the lock-files though with micromamba, right, and that the fix for you was micromamba install mamba
right? My wild guess is that there were issues with virtual packages that were fixed in conda (I did one of the PR by the way). Because micromamba reimplements these parts, they were issues, there is a small chance that someone reported it and that it was fixed.
I am not convinced the "lot smaller" this matters that much in practice for the, CI maybe you save a few seconds for the downloads and 2-3 lines for the installation code.
All in all, I would be in favour of being conservative here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution for me was to install both mamba
and conda
to be able to update lock files.
The smaller thing is significant since micromamba
doesn't come with a base environment. So there's one whole environment saved by not using conda
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is already a net improvement. Can we discuss micromamba
in a follow up PR?
MINIFORGE_PATH=$HOME/miniforge3 | ||
bash ./miniconda.sh -b -p $MINIFORGE_PATH | ||
source $MINIFORGE_PATH/etc/profile.d/conda.sh | ||
conda activate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is already a net improvement. Can we discuss micromamba
in a follow up PR?
If you want to Loïc we could update
|
I updated Having said that the changes look simple enough, so it should be fine. |
Because we are using
explicit
lock-files, this is a format that conda knows about and there is no need to install conda-lock to create the environment if you only have conda package in the lock-file. If you have pip package in the lock-file you need to use conda-lock.For more details, see https://conda.github.io/conda-lock/output/#explicit-lockfile.
This PR also cleans up a few things:
build_tools/shared.sh
and reuse it for all CI install scripts.Not that crucial, but this may speed up things a tiny bit (~20s on my machine) for a few builds: