Hi! I wanted to know if it's possible to show nest...
# pipeline-maintainers
q
Hi! I wanted to know if it's possible to show nested parameters on the parameters section of the docs? I have a pipeline (in dev mode) with nested parameters, but only the parent group is shown here, although the nextflow_schema is properly documenting all the parameters Any idea? 🙂
j
No, we've never allowed nested parameters (even if we didn't lint/check for it, TBF), because apparently it is a horrible can of worms
@Phil Ewels and @mashehu are the ones who have normally tried to tackle that in the oast
q
It seems to work really well for me at least Using a
-params-file
make it very convenient to provide nested arguments
j
Ah sorry to be clear I mean it doesn't work well with rendering on website/launch stuff
Technically it works from the nextflow side
p
It was a decision we made when designing the schema. There is an issue open about adding support for it, but we put it on ice as longer term support in Nextflow is unlikely
👍 1
With the new config parser (eg. using strict syntax) I think that it's not supported
You can provide a map to a param, but you have to override the entire map if you want to change anything. You can't use dot syntax to set specific leaves on the nested param structure, if that makes sense.
Nextflow was never intentionally designed to do this, apparently it was just an accident that it ever worked 😅
q
In my case, having nested params is necessary: we support multiple segmentation tools, and they all come with their own config. For instance,
params.segmentation.baysor
for parameters specific to baysor (a segmentation tool) - see example here, or
params.segmentation.proseg
. If we flatten the params, we loose the original official baysor parameter names, and we’ll need to do a manual mapping for every single one. The second reason is that, by default, we don’t know which segmentation tool(s) will be used. Therefore, having groups is a good way to check which tool to run: e.g. if there is something in the
baysor
params, we run baysor. If we flatten everything, we’ll need global defaults, but they need to be provided per group (we either all or none params of each group).
So having groups of params is super convenient in this case, and I think flattening everything would lead to a (i) need of a massive parameter renaming when passed to their associated tool, (ii) increased maintenance complexity, (iii) difficult user experience and (iv) more complex params validation
p
Feel free to hop on the thread above and make your case (better placed than here)
✅ 1
NB: It's the Nextflow slack, not nf-core. You can join here.