-
Notifications
You must be signed in to change notification settings - Fork 189
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
POC: module yaml restructure #2789
base: dev
Are you sure you want to change the base?
Conversation
…cesses, for meta.yml
Created an issue to track this in the modules repo: nf-core/modules#4983 |
Good timing! we need to discuss about this, meta.yml is becoming essential to unlock multiple critical features (types checking, output schema, generative workflows), I think we need to promote it as a nextflow "standard" |
Hello, I would like to take over this PR and want to make sure we are on the same page before starting. I think we agreed on the new input:
- #input tuple
- meta:
type: map
description: |
Groovy Map containing sample information
e.g. [ id:'test', single_end:false ]
- scaffold:
type: file
description: Fasta file containing scaffold
pattern: "*.{fasta,fa}"
- fasta:
type: file
description: FASTA reference file
pattern: "*.{fasta,fa}" The next steps that should be done first are:
To update the file, I see two options: either add the new Does that seem good to you? |
@mirpedrol yes that sounds good. For pipeline linting, we already have the flag Could we have the same approach here? |
Proof of concept showing minor change to the parsing of module processes, to correctly capture structure of inputs. Currently just dumps a hypothetical YAML string to the console when running linting, eg:
Just a starting point. If we want to fix all module metas, needs a lot more work:
meta.yml
is built when creating a new module from the templateoutput
as well asinput
meta.yml
is used and update accordinglyRelated / would fix: