OK, so who wants to yell at me about workflow outputs conversion? https://github.com/nf-core/rnaseq/pull/1679 I figure folks might want opine so I set a good example. I think it's time rnaseq got its 4.0.0 release (finally) after this and other syntax changes, so I've gone a bit gung-ho with removing

params.outdir

, because semver.

There was some discussion about setting

outputDir = params.outdir

in the config by default, to provide a transition to users. Is that still on the cards anywhere? Otherwise, at a quick glance my only thought is that you have an awful lot of outputs. I wonder if it's useful, in the absence of record types yet, to group outputs by process/subworkflow/analysis type (some unit that's useful to you), join them in a deterministic order, and pass those back down to the entry subworkflow? That way you're passing less things and it might make the scripts a bit more manageable.

I recommend a less drastic solution to drop params.outdir. apart from that looks good to me

You can't remove outdir until Seqera Platform actually has a built-in method to set it nicely

I noticed that for reports it's much easier to put them in a multiqc specific topics, and I started playing with this in rnavar

Thanks guys: 1. Totally agreed on the large numbers of outputs, I'm already tinkering with some limited grouping. I may be able to group further at the cost of tinkering with the output structure, which I'll do in a separate PR, the objective of this one is a drop-in replacement and then I can iterate. I did also consider your solution @Jim Downie, I'll maybe take another look. 2. OK, will keep outdir, though I resent it 3. Yep, looking forward to further optimisation standards like multiqc thing we were talking about

Keep outdir for now until the template catches up

I don't think the join-and-map is a goer for rnaseq, channel structures and metas are more variable

I suggested this too. But I think it might slightly overkill, and hard to normalize outside of just files for MultiQC

Not having so many layers of workflow code would also be good 😉

meh, hierarchical organisation of code makes sense to my brain, it's just not working too well with this syntax

I said this to Maxime before, but I'm not a big fan of the idea of just dumping everything into a topic and implementing 'publishDir but with the output block' - I think it means you lose out one of the core advantages of the switch to publishing by channels, which is that you are not confined to only using the metadata fed into a particular process to define the outputs - you can combine channels in new ways and use combinations of metadata when publishing. For example in one of my pipelines I take in some stuff, drop the unique identifier and run processes on the de-duplicated inputs. Then I need to match things back to the identifier before publishing - if I went from a topic straight to outputs, this would not be possible. In general I think joining outputs together at a subworkflow level into a single Record/Tuple/Map before emitting will help keep like data together while simplifing the emission to different levels.

If it were just me, we would just publish all via hashes, and no architecture

I would like to be able to just dump everything into a topic at my discretion though, I think it would cover most of my basic use cases, and metadata can be formulated early on so a process receives everything that might be helpful. But it's a bit academic, Ben has nixed the idea anyway 😉