Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tsibley
Copy link
Member

@tsibley tsibley commented Oct 30, 2024

See commit messages. Opening for visibility and soliciting commentary. Not for merge yet.

Checklist

  • Checks pass

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
@tsibley tsibley changed the base branch from main to trs/remove-hardcoded-references October 30, 2024 20:23
Base automatically changed from trs/remove-hardcoded-references to main November 6, 2024 22:17
Comment on lines +9 to +14
# 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"
Copy link
Member

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 --configfiles) 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.

Copy link
Member Author

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.

Copy link
Member

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.

@jameshadfield
Copy link
Member

I'd like to see config parsing such as this become part of our general snakemake workflows regardless of workflows as programs CLI work.

@tsibley
Copy link
Member Author

tsibley commented Nov 12, 2024

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 🙃)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants