<!channel> (sorry for the 'at', but this will be o...
# rnaseq_dev
j
<!channel> (sorry for the 'at', but this will be of interest to a few folks) I've implemented the new output syntax in this PR https://github.com/nf-core/rnaseq/pull/1679. It's ready to go, and replicates the existing publish behaviour perfectly. BUT it's very verbose, and will be much nicer when the record type syntax is finalised (see https://github.com/nextflow-io/nextflow/issues/6756#issuecomment-3794906949 for detail on that). I'm partly inclined to merge it and put up with the verbosity until record types save the day, but we can also hold off. What do folks think? āœ… = Just merge it, it works, it will be nicer soon āŒ = Nooo, the emits! They burn!
āœ… 2
āŒ 1
p
That's.. a lot of emits šŸ˜…
j
i know right?
b
there's no rush
p
CleanShot 2026-01-27 at 16.09.13@2x.png
j
Yeah, but it's done, and it's not THAT bad.
p
How bad will the refactoring be to add record types? Easier to do in two steps, or in one go?
j
That's kind of what i mean, this is half way there because I've made sure the right emits are happening everywhere. The record types will then just be a merge of a lot of those emits.
šŸ‘šŸ» 1
r
I feel like the number of emits could be reduced if we grouped related items. For example, it would seem sensible to me that ALIGN_STAR.out.bam and ALIGN_STAR.out.bai should be emitted as a single channel - the bai makes no sense without its cognate pair. At the more extreme end, we might consider larger groupings of semantically related outputs into single channels.
Maybe I'm not thinking about this correctly, but I don't understand the convention of breaking apart related items. Files and their indices are the most obvious example. I'm struggling to think of a situation where I'd want a channel of indices without their source. Every time we separate the index from the source, we're just making more ceremony for ourselves to have to join them back up again every time we need to use the index (because they're useless without the source). It also creates extra ceremony in the workflow outputs. We take a channel of fasta files (or more likely a single fasta file), send it through an index process, ditch the fasta file, keep the index, and then reunite the index to the fasta each time we use the index. For example, is there a reason we couldn't use
ch_indexed_fasta
rather than
ch_fasta
and
ch_fai
? e.g. replace
Copy code
workflow BAM_MARKDUPLICATES_PICARD {
  take:
    ch_reads
    ch_fasta
    ch_fai
  main:
    PICARD_MARKDUPLICATES ( ch_reads, ch_fasta, ch_fai )
}

process PICARD_MARKDUPLICATES {
  input:
    tuple val(meta), path(reads)
    tuple val(meta2), path(fasta)
    tuple val(meta3), path(fai)
   ... 
}
with
Copy code
workflow BAM_MARKDUPLICATES_PICARD {
  take:
    ch_reads
    ch_indexed_fasta
  main:
    PICARD_MARKDUPLICATES ( ch_reads, ch_indexed_fasta )
}

process PICARD_MARKDUPLICATES {
  input:
    tuple val(meta), path(reads)
    tuple val(meta2), path(fasta), path(fai)
    ... 
}
Same would go for things like • markdup_bam + markdup_bai • star_bam + star_bai • umi_dedup_bam + umi_dedup_bai • umi_dedup_flagstat + umi_dedup_idxstats + umi_dedup_stats • sorted_bam_flagstat + sorted_bam_idxstats + sorted_bam_stats • markdup_flagstat + markdup_idxstats + markdup_stats
a
because the nf-core rulez say so
In truth, it's probably a convention that's emerged rather than designed. Skinny tuples are easier to teach to newbies vs fat tuples are probably a better design pattern.
j
I think 'da rules' would allow me to create combined channels with indices without getting shouted at, though it probably wouldn't make a massive difference. flagstat etc less so
old man yells at sarek 1
m
So following my experiments with topics files for some reports, I have played with topics for all files that are needed by MultiQC: https://github.com/nf-core/rnavar/pull/285 I believe it could be something nice to go for, and much more simpler on the output side
ā¤ļø 1
check the
modules.conf
,
workflows/rnavar.nf
and
<http://main.nf|main.nf>
the files captured in the snapshots just denotes path changes and rescuing a samtools stats file that somehow was not published before