Providing input a typed param does not work when there is an `include` in the script that has a `params` block as well

[VasLem]

Bug report

Example:

test2.nf:

params {
    test2_param: String = "test2"
}
process test2 {
script:
"""
echo ${params.test2_param}
"""
}

test1.nf:

include {test2} from './test2.nf'
params {
    test1_param: String = "test"
}
process test1 {
script:
"""
echo ${params.test1_param}
"""
}

workflow {
main:
test1()
}

Then setting test1_param:

nextflow run test1.nf --test1_param "hi"

 N E X T F L O W   ~  version 26.02.0-edge

Launching `test1.nf` [hungry_stone] revision: 39af0968aa

Parameter `test1_param` was specified on the command line or params file but is not declared in the script or config

but also neither for test2_param:

nextflow run test1.nf --test2_param "hi"

 N E X T F L O W   ~  version 26.02.0-edge

Launching `test1.nf` [big_raman] revision: 39af0968aa

Parameter `test2_param` was specified on the command line or params file but is not declared in the script or config

Environment

• Nextflow version: version 26.02.0

[bentsherman]

Indeed, only the params block in the main script is used. When you include a module, any params block in that module is ignored

[bentsherman]

Related: #6769

[VasLem]

Hi Ben, thanks for the reply. However, this is a different problem, as test1_param is defined in the main workflow , but still I receive an error. Anyways, this behavior makes it impossible to use sub-workflows logic, I had to revert all the typed parameters, as I am heavily dependent on this architectural pattern.

[bentsherman]

I see, I misread your example. So this is actually a bug, seems to happen when including a module with a params block

To your point about subworkflows, the idea is to pass params into subworkflows as inputs. This is admittedly tedious without records. However, record types are included in 26.03.0-edge, so you can try it out that way

[VasLem]

Thanks for handling the bug so quickly! I understand. So my current setup is always having a script with a subworkflow and an entrypoint within it, at the main.nf, so I can either use it directly by calling that folder, or include the sub-workflow from a different workflow, which has been a really neat approach. But what you are saying is probably that I have to separate those two at different files, and use records as input parameters to the sub-workflow... is there any chance we could support multiple params blocks lookup in the future? I could use Claude to refactor the whole codebase, which amounts to about 100 workflows/sub-workflows, but I feel very restrained by this factor, it is as if sub-workflows are flattened to groovy functions, I could use a def function to do the exact same thing as a "new" sub-workflow...

[bentsherman]

What I would do is define a params/entry wrapper around the subworkflow in the same module:

// hello.nf
workflow HELLO {
  take:
  params

  main:
  println params.message
}

params {
  message: String
}

workflow {
  HELLO( params )
{

This way you can run the subworkflow directly or call it from a larger workflow:

// main.nf

include { HELLO } from './hello.nf'

params {
  message: String
}

workflow {
  HELLO(params)
}

[VasLem]

Ah that's cool, I didn't know you could consider params as records and pass them directly, thank you for the informative example!