-
Notifications
You must be signed in to change notification settings - Fork 719
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
Use module config #1112
Use module config #1112
Conversation
|
Thanks @bentsherman !! 🙇🏽 We have refactored all of the module / subworkflow locations on Can we call the file
We did agree on a convention / standard for this but I can't remember what it was now. Maybe that we would suppress those warnings by default and have a special profile where they are printed for developers. |
Signed-off-by: Ben Sherman <[email protected]>
b422c87
to
4218fd7
Compare
Thanks, I was avoiding
The thing is that the module config is special because it assumes the process scope (check the PR files to see what I mean), and I think the file name should reflect that. If we call it If we want to make the file name arbitrary, then the module script will have to include the config file directly. We could add support for |
Actually I was wrong about this. There were no config selector warnings even though I removed all of the if statements. This is because the module config is not applied to the process until the process is actually invoked. So we are good to go in that regard 👍 |
Signed-off-by: Ben Sherman <[email protected]>
I tried to move the module config closer to the process modules rather than the workflows that invoke them. There is an art to this as it depends on what you consider to be sensible defaults for a process. Where two workflows call the same process with different config, I try to intuit which config is the "default" config and move that one. But the maintainers should really go through the config and decide how they want to organize the module configs. |
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Closing in favor of the approach proposed here: nf-core/fetchngs#308 |
This PR refactors the modules config to be local to each module, using nextflow-io/nextflow#4510. So the config for a process now resides in a
module.config
next to the workflow that calls the process.Some notes:
Definitely needs to be validated to make sure that the various configs are applied with the correct priority. Note that pipeline config overrides workflow config overrides process config, etc.
Doesn't really change much if we're putting the process config next to the calling workflow. Most of the
modules.config
still resides in one big file next to thernaseq
workflow module.Doesn't really solve the problem of if statements in the config file. I believe they were added to avoid the config selector warnings when a process selector points to a process that isn't used in a particular pipeline run.
Paolo originally proposed a more programmatic syntax in which the module config is just a map and the process invocation must reference. I decided to go with process selectors first because the syntax is familiar and it provides resolution from different scopes (pipeline > workflow > process).
Based on these findings, maybe a better convention would be to put the config for each process in the corresponding process module.
@ewels @drpatelh let me know what you think!
PR checklist
nf-core lint
).nextflow run . -profile test,docker --outdir <OUTDIR>
).docs/usage.md
is updated.docs/output.md
is updated.CHANGELOG.md
is updated.README.md
is updated (including new tool citations and authors/contributors).