-
Notifications
You must be signed in to change notification settings - Fork 254
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
feat: automatic conda environment handling #1469
base: master
Are you sure you want to change the base?
Conversation
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 find this a super nice and consistent approach! Perhaps we think about the case on how to deal with custom installations?
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.
In general, I also like the idea of using --sdm conda
more!
The way this PR is currently set up, the conda_env_provider()
can only be used with the pinned versions. However, while developing, it can also be quite useful to set
conda:
"../envs/environment.yaml"
Because "software-env" is one of the --rerun-triggers
(i.e. changes to environment.yaml
will conveniently trigger reruns of the affected rules). Perhaps, there should at least be a toggle in the configuration to use pinned versions or environment.yaml
directly as @lkstrp reluctantly suggested, e.g.
pinned_environments: true
Has someone looked into snakemake
's recommendations for reproducible environments?
@@ -81,7 +81,7 @@ rule create_scenarios: | |||
output: | |||
config["run"]["scenarios"]["file"], | |||
conda: | |||
"envs/retrieve.yaml" | |||
conda_env_provider() |
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.
Maybe it makes sense to allow an argument here to a file "envs/retrieve.yaml" or similar/its pinned version?
I think there is some untapped potential to use rule-specific environments rather than one large environment.
Changes proposed in this Pull Request
Add option to let snakemake handle all conda environment handling based on pinned envs and os
Makes it unneccessary for a user to wrangle with dependencys and envrionments at all
Only snakemake would have to be installed. Then you could run
snakemake ... --sdm conda
and theA few things to discuss:
environment.yaml
with snakemake (was the setting before, not sure if anyone uses it). Also it is not robust as only pinned envs are checked by the CI.run.env=pinned
andrun.env=base
).--sdm conda
is not added, the setting will do nothing.--sdm conda
by default (or if set in config, e.g.deployment_method=pinned
)._helpers.py
needs some dependencies and is loaded before snakemake handles the environments. But this module would benefit from being broken up anyway.Checklist
config/config.default.yaml
.doc/configtables/*.csv
.doc/release_notes.rst
is added.