i updated records in github.com/pinin4fjords/rnaseq-diffabundance-meta to match our decisions, it all still runs

@James Fellows Yates, the bot says

⏺ Found another issue: in 26.10.0 Tuple takes no type parameters, so Channel<Tuple<Map,Path>> won't compile, losing the ability to declare element types at workflow boundaries.

JAMES LEAVES HIS COMPUTER UNLOCKED, AND IT'S BAD

I LOOOVE SAREK btw

😆

I went through all modules to check what kind of meta keys we use. here is the quick and dirty analysis:

I MIS PRESSED THE STUPID LOCK SCREEN KEYS STUPID MAC!

Still finalising but POC in progress for the proposed 'regression' ( 😛 ) is here github.com/pinin4fjords/rnaseq-diffabundance-meta/pull/14

@Björn Langer points out we need a few more real/pseudo code examples to demonstrate our pros/cons for the debate tomorrow

Should we prepare some background slides as well for the debate tomorrow?

Is it possible to tune into the debate remotely? I would love to listen if it was possible

Hello friends. I went through today's chatter and left some comments. Looking through the decisions doc, I pretty much agree with everything there so far. I heard there will be a debate tomorrow so I will leave my thoughts:

• Anonymous records and one record input -> one record output for processes should give you the most flexibility and minimize the record type overhead

• Keeping meta is sub-optimal but I think for nf-core it is necessary, since users want to be able to override tool args at runtime. My second methylseq PR shows how to do this, and I think Jon took a similar approach in his meta-pipeline. The important thing is that ext can't be the only way to supply tool args. A record input with ext override gives you the best of both worlds.

• I heard about a proposal to keep using tuples for process inputs/outputs with static typing. Don't do this. It is not the way. I'm happy to discuss this in detail, and I will add more in 🧵 , but here I just want to make clear that I do not think this is a viable path for nf-core.

So I had a passing thought. What happens with the workdir when using meta pipelines? • Do we get a working dir per sub-pipeline? • Does everything go into one huge directory? • Can we selectively delete the workdir for each sub pipeline while keeping resumability? I can see this go very wrong very fast on some HPC clusters

<!here> https://nfcore.slack.com/archives/C07ACNLELR2/p1792139793379529?thread_ts=1792102821.217429&amp;cid=C07ACNLELR2

message has been deleted

We're starting now! <!here>

github.com/nf-core/rnaseq/pull/1945 github.com/nf-core/rnaseq/pull/1966

Deling with args for module inputs github.com/nextflow-io/nextflow/pull/7260

A draft of the new guidelines for modules: hackmd.io/YmVPL55sTomtFIpNKlRKBA I'm still working on it but feel free to comment if I did something stupid

What's the logic behind:

All ext variables SHOULD be specified as a independent directive of the modules instead using def prefix = ... in the script block (based on <https://github.com/nf-core/modules/pull/8808/changes>). These variables SHOULD be defined as closures to make sure these work in all cases.

Looking at the example I find this more unclear than the existing pattern as the definition is moved further away from where it is used.

Many of us found this cleaner as it reduced some code. It just never got integrated and it seems like now is good time to bring it in since there's going end up being linter changes

One idea I wanted to follow up from the above thread: https://nfcore.slack.com/archives/C07ACNLELR2/p1792102821217429 Jim briefly mentioned his idea about calling processes like functions. Now that everyone has the relevant context fresh in their minds, I thought it might be worth asking about this again. To be clear, this is what he's talking about:

ch_samples.map { r ->
    BWA_MEM(
        id: r.id,
        reads: r.reads,
        bwa_index: r.reference,
        args: "--my-arg",
        args2: r.single_end ? "--single-end" : ""
    )
}

In fact, I considered this approach for 26.04, but ultimately dropped it out of concern that it would "obscure" the process calls in the workflow logic. Most people think of nextflow as "processes connected by channels", and this approach kinda inverts that mental model But I think Jim is correct that this is likely the "cleanest" way to deal with naming conventions and adapter logic What do you think about this at a glance? I don't think it's a blocker for migration, but it is one of those "nextflow features" we could add to ease the pain. Just some food for thought