https://nf-co.re logo
Join Slack
Powered by
s
message has been deleted
j
no
just you
yes
i can send my link
it's the third code block i think
To be clear, this is a suggestion for syntax that doesn't exist!
sorry, I don't have microphone access in Slack for some reason
n
no worries we see your messages
👍 1
j
bye!
m
So that was a bust 😅 I could hardly understand anything
j
Me either!
I am sure they decided on all the sensible things
m
ah yes, “sensible”
n
oh sorry 😅
we basically decided to use record types and we don't care about input field names
❤️ 2
j
great
And there was discussion about timing, what was the resolution?
m
I claim all the 
foo
and `bar`’s !
n
It's going to be a gradual migration with some bulk transitions using LLM's over time
👍 1
A bit dependent on what pipelines do their conversion
j
Makes sense
m
We’ll be on the frontier of nextflow development
🤣 1
j
Are we keeping 
meta
?
n
Awesome! Glad you guys also approve 😛
Yes meta will be a record required in each record input
👍 1
j
I mean, I have /thoughts/. But I like the solution that everyone likes, the most
🎉 1
a
@Nicolas Vannieuwkerke does that 
meta
break the 
nextflow module run ...
functionality for pipelines, or is that the tradeoff? In 
26.10.0
, someone could pass in a csv of something like 
id,bed,fasta
and generate the channel of records; but in a quick test, that didn't seem to work when 
meta
is a record. It has been good to follow this conversation since it is something I am currently wrangling with myself
n
That's actually a good question! @Ben Sherman would you happen to know this?
b
that's a good point. the automatic samplesheet -> record channel mapping doesn't do anything special for 
meta
like nf-schema does. you would have to either: 1. use JSON/YAML with meta fields already grouped in a 
meta
object per sample 2. not use 
meta
in the workflow input record (likely not feasible if pipelines expect to call the workflow with 
meta
) so it sounds like 
nextflow module run
for workflows is another casualty of keeping the meta map 😅
n
shared a GIF
Is there something we can do about this you think?
b
well, not being able to run nf-core subworkflows directly is not the end of the world
but I think the only real solution is to get rid of the meta map
n
yeah that's sadly not going to happen very soon I'm afraid 😅
b
I think that's okay for now
sounds like another point in favor of this idea...
💯 1
100 rainbow 1
meow yes 1
a
I think what Ben said makes sense in that a subworkflow requiring the meta and not using the nextflow command can be an okay tradeoff, if the intent is that people are typically composing / chaining workflows that generate the 
meta
internally. But I'm also someone sitting in the sidelines watching to see what you all settle on
n
We've decided to tweak the guidelines on this a bit and make 
meta
fully optional. All required meta fields are now inputs to the process. Meta can still be used by pipeline developers this way but it should not interfere with 
nextflow module run
anymore this way
a
Interesting! Well thanks for looking into this everyone, I appreciate the effort put into it.
That may even be the best of both worlds; anything required is explicit, but additional meta the dev wishes to maintain can be passed through with the meta.
🎉 1
Open in Slack
PreviousNext
Powered by