Workflow output DSL (channel selectors) #302
Conversation
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
Signed-off-by: Ben Sherman <[email protected]>
|
My initial reaction is... I guess we could implement both and see where users land? It would be confusing to have both approaches, but not as confusing as I originally thought |
|
This is is sooooo much better IMO. Bye bye process selectors and file globbing! Thanks @bentsherman . I was hoping we'd be able to incorporate this into the emit somehow: But that's based on next to no understanding of how the Groovy internals work, so what you have here makes me happy. I am wary of implementing both, purely because people would then use both and we'd end up in Perl-like wild west situations with mutually incomprehensible code. |
| emit: | ||
| runinfo_tsv = ch_runinfo_tsv | ||
| fastq = ch_fastq | ||
| fastq_md5 = ch_fastq_md5 | ||
| samplesheet = ch_samplesheet | ||
| mappings = ch_mappings | ||
| sample_mappings = ch_sample_mappings_yml | ||
| sra_metadata = ch_sra_metadata | ||
| versions = ch_versions.unique() | ||
| versions_yml = ch_versions_yml |
There was a problem hiding this comment.
Although this requires more code to return the channels, I think overall the code will improve as people have to start thinking about their workflows as functional units.
| properties: | ||
| sample: | ||
| type: string |
There was a problem hiding this comment.
Could this information be encoded in the output block? We could generate this with the output, instead of alongside it.
It feels kinda redundant having to maintain a separate file which only does output validation. On the other hand, it might get very messy in the output declaration if you are having to type everything.
bentsherman
changed the title
|
I didn't say this directly, but I think this is 10000% times better than the solution based on process names. |
Alternative to #275 which uses workflow output channels instead of process selectors