Hello team! Me and @James Fellows Yates are arguing on two points in this PR: https://github.com/nf-core/modules/pull/9665 We would like some extra input from the maintainers team if possible. First point is this comment: https://github.com/nf-core/modules/pull/9665#discussion_r2708365740 According to the rule (https://nf-co.re/docs/guidelines/components/subworkflows#input-channel-name-structure) subworkflow inputs should be either ch_ or val_ prefixed. My own addition (which I follow in my pipelines in general) is also having skip_ prefixed flags (instead of val_skip_) that are used to control the flow logic throw conditionals (e.g., skip_preprocessing). I love sticking to the rules, but this skip_ naming seems more intuitive to me. What are your thoughts on this one? Should I go for val_skip_ or if you like just skip_, maybe update the rules for this case?

I like using

skip_

and would vote for adapting the rules

I think it’s okay; some of these prefixes will become obsolete or redundant with static types anyway, right?

Note I'm less particular about thethe

skip_

thing versus the other issue. However note if you allow

skip_

you should then also allow the

run_

variant. But also if we are talking about a specifici boolean input type, it might not be controlling just

skip

or

run

of a process, but maybe controlling something else like

activate

a mode in a tool or

remove

something... so it turns into a can of worms IMO 😉 But it doesn't 'break' anything

Oh, look, there are guidelines 😮

THERE ARE

Oh, look, the second point is out of date

you all like to live in chaos

I just like arguing with you James

And me too with you Simon ❤️

I personally really don't care what your inputs are called as long as it's clear what is what 😛

I think it was also to help better guide like if we want to do massive syntax changes, having consisten nextflow types indicated it would be easier to search and replace

Agreed that this will be a moot point when we switch to static typing, as the input will be specified as:

workflow X {
    take:
    skip_X: Bool

Which will make understanding what each thing is more clear. You could even have

bool_skip_X

if you really preferred 🥲 For now, I think prefixing with

val_

is not a terrible idea, to differentiate the input type as a value/value channel rather than a queue channel. But I'm not wedded to it and if you think it improves clarity I could be convinced to let such a thing slide

I had no idea that we were supposed to prefix

ch_

or

val

in subworkflows

For now, I think prefixing with val_ is not a terrible idea, to differentiate the input type as a value/value channel rather than a queue channel. But I'm not wedded to it and if you think it improves clarity I could be convinced to let such a thing slide

That was wah tI said to @Evangelos Karatzas on the PR but he still wanted to bring it here for a fight 😆

We'll roll on the mud!!!

It looks like most of the subworkflows do indeed use

ch_

anything without ch_ would be val...correct...

I think

skip_

is obviously going to be a boolean

I would rather go with

bool_

in that case though

Clean code...will stick with

skip_

😛

Yeah that's fine, but you have to update the guidelines

Isn't team docs more suitable for this? 😛

Nope

f i n e . . .

also you have to update the bit about versions.yml 😉

=> https://github.com/nf-core/website/pull/3707

What's that about? didn't get the versions.yml thingie and the link :P

Not related to this thread so nvm 😁

How does this look? https://github.com/nf-core/website/pull/3724 (Docu update)

"For example, input channels with multiple elements (e.g., meta map + file) should be prefixed with

ch_

." I think this mistakes queue channels for tuples? Any queue channel (a channel with more than one entry) should be prefixed with

ch_

, whether it is of the format

[meta, thing]

or just a channel of multiple

thing

?

I left this as it was, but I thought the same as you. Should I change it?

I would say so

Updated

I think that still misses the difference slightly -

[ file_1, file_2, file_n ]

would imply a channel with a single entry which is a list, which could technically be a queue channel (is consumed by a process) or a value channel (is used repeatedly by a process if there is another queue channel input that is longer)

you are right! i just got the theory down