Conversation
|
The majority of the param conversion is done by a python algorithm. Some changes are simple, only changing the word "config" into "param". The complicated part is in I believe its better to just add in param |
|
Hey @virio-andreyana, I would not pass the whole config but use the sections which are really needed (even if it is a lot). Imagine you just want to alter some colours for the visualization of results (which happens after the solving), then the whole solving process would be retriggered. |
This is a re-do for the pull request in #296.
Changes proposed in this Pull Request
Use the
params:section in rule definition to keep track of changed settings inconfig.yaml.https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html#non-file-parameters-for-rules
The goal is that rules for which parameters have changed rerun automatically.
This can currently be done with:
https://snakemake.readthedocs.io/en/stable/project_info/faq.html#how-do-i-trigger-re-runs-for-rules-with-updated-code-or-parameters
snakemake -n -R `snakemake --list-params-changes`or
snakemake -R $(snakemake --list-params-changes)This will be even more convenient, once this
snakemakePR is released:snakemake/snakemake#1107
or
(which would also include code changes)
It seems to work very nicely to pass lists/dicts as params, which would help us keep config "blocks".
This PR is not complete yet, but a proof-of-concept for a selection of config settings. We can discuss from here and complete later.
Rules Checklist
Script Checklist
Checklist
envs/environment.yaml.config.default.yaml.doc/configtables/*.csv.doc/release_notes.rstis added.