Nested params default subset

[VasLem]

I recently discovered this awesome, undocumented feature regarding nested parameters setting in nextflow.config:

params {
 d {
  v = 1
 }
 a {
  v = 2
 }
 b {
 v = 3
 }
}

which allowed a workflow/process to access variables using, .e.g., params.d.v

I was also surprised to see that this also worked

params {
 d {
  v = 1
 }
 a {
  v = d.v
 }
}

with params.a.v equaling 1.

So, I thought, it would be nice to have a nested parameter set that could control the behavior of the rest, so something like that:

params {
 d {
  v = 1
 }
 a {
  v = d.a
 }
 b {
 v = b.a
 }
}

Then, if the user wanted to change the v configuration for both a and b, to let's say 2, they would just run nextflow with --d.v 2

However, to my slight disappointment (finally, lucked out), plugging this parameter in the command line did not change the values of a and b. Then, I reminded myself the order of parameter substitution in Nextflow, and I thought, well, this is not satisfying the condition, as, in theory, first the parameter d.v would be set, followed by the parameters a.v and a.b, I don't think what I am mentioning can be considered a bug, due to the largely undocumented part of it. Still, it would be nice to be able to keep all the parameters for the entire workflow, nicely organized in such a structure.

Unfortunately, I am not familiar with the Groovy code, and I kind of believe this is part of the core architecture, so I am not sure if I can contribute more, I am just checking if such a feature is also something you would consider.

[bentsherman]

This nested params usage is more an implementation artifact rather than an explicit feature that we support. I would not rely on it for the long term. But the issue in your case is that a.v and b.v are evaluated before your CLI param is applied, so they will not be updated. I might address this in a future version but still undecided