-
Notifications
You must be signed in to change notification settings - Fork 6
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
wip! workflows as programs prototyping #55
base: main
Are you sure you want to change the base?
Conversation
XXX FIXME: rationale, relationship to "workflows as programs" XXX FIXME: alternatives considered (but declined) for path-in-config-value handling XXX FIXME: document layout/structure of workdir
# Use default configuration values. Extend with Snakemake's --configfile/--config options. | ||
configfile: os.path.join(workflow.basedir, "defaults/config.yaml") | ||
|
||
# Use custom configuration from analysis directory (i.e. working dir), if any. | ||
if os.path.exists("config.yaml"): | ||
configfile: "config.yaml" |
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 behaviour of multiple configfiles is somewhat documented but I think will prove a tripping hazard to people.
Multiple configfiles (as per this section of code, and/or via additional --configfile
s) will overwrite scalars and lists; dicts will be merged, but nested dicts won't be; there's no way to remove a dictionary key as far as I can find.
This has implications for how we structure configs, specifically around how we encode flags to skip rules or skip a particular argument.
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.
Nod, for sure, but "multiple config files" is already our established approach, so this is making that more accessible/standard but isn't changing approaches.
We could change approaches, though, by combining the configs ourselves outside of Snakemake's machinery. I didn't think there was appetite for that, but it's very possible.
dicts will be merged, but nested dicts won't be; there's no way to remove a dictionary key as far as I can find.
Hmm. In my recollection (and testing right now), nested dicts are merged? That is, the config merge is deep.
The merge is additive though, so yes, there is no way to remove keys.
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.
nested dicts are merged
Oh yeah, I wasn't formatting my YAML correctly. That they are merged will be very helpful for us.
I'd like to see config parsing such as this become part of our general snakemake workflows regardless of workflows as programs CLI work. |
Agreed! (ever since I started 🙃) |
See commit messages. Opening for visibility and soliciting commentary. Not for merge yet.
Checklist