The

CLAIR3

module declares some output channels:

output:
tuple val(meta), path("*merge_output.vcf.gz"),            emit: vcf
tuple val(meta), path("*merge_output.vcf.gz.tbi"),        emit: tbi
tuple val(meta), path("*phased_merge_output.vcf.gz"),     emit: phased_vcf, optional: true
tuple val(meta), path("*phased_merge_output.vcf.gz.tbi"), emit: phased_tbi, optional: true

And I have just discovered that when you have

phased

then they also end up in the

vcf

channel, meaning that channel has variable

arity

. I’m unclear on whether this is intended, but it’s a real pig to handle right now and it seems unintuitive - to me at least - that the phased files end up in two channels?

oooh

So unless this PR is merged, then there is no

prefix

on the outputs (the tools just outputs

merge_output.vcf.gz

and

phased_merge_output.vcf.gz

by default). I noticed this issue because in the stub we touch both, but I don’t actually know if the

phased_merge_output

replaces the normal

merge_output

in a real run, because I have never used the phasing option of

CLAIR3

myself

I am totally un-aware about who uses this tool. Let's check with @Robert Forsyth

IIRC the issue will be that we can’t use negative matching on the output globs and thus without a

prefix

we can never stop

phased_merged_ouptut.vcf.gz

ending up in

vcf

channel?

I agree with you

Locally I can patch to enforce a prefix, but I am not sure if that is desirable in the remote.

I'd rather we patch as it should be done properly upstream