Boolean flag default to `true` set to `false` through CLI is interpreted as a string

[VasLem]

Bug report

Currently there is no way to set a boolean flag defaulting to true to false naturally, unless you set it as typed.

Minimal example:

params.flag = true
process test {
script:
if (params.flag) {
    println "Flag is true"
} else {
    println "Flag is false"
}
"""
echo ${params.flag}
"""
}

workflow {
main:
test()
}

Run:

nextflow run test.nf --flag false

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

Launching `test.nf` [nauseous_visvesvaraya] revision: d3b98b5758

executor >  local (1)
[9d/b25e5a] test | 1 of 1 ✔
Flag is true

Expected behavior and actual behavior

I would expect to have the flag set to false, or at least have a way to do so, without using a typed param. This goes totally against the old CLI behavior.

Environment

• Nextflow version: 26.02.0-edge

[scwatts]

Here is another example where just setting a boolean parameter on the CLI results in the variable becoming a string:

params.boolean_flag = false

workflow {
  println "boolean_flag: ${params.boolean_flag} (${params.boolean_flag.getClass()})"
}

Run with default → boolean (expected)

$ NXF_VER=26.02.0-edge nextflow run ./main.nf

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

Launching `./main.nf` [spontaneous_yalow] revision: fa0d8aee84

boolean_flag: false (class java.lang.Boolean)

Run with boolean_flag set on CLI → string (unexpected)

$ NXF_VER=26.02.0-edge nextflow run ./main.nf --boolean_flag

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

Launching `./main.nf` [deadly_baekeland] revision: fa0d8aee84

boolean_flag: true (class java.lang.String)

This appears to be impacting a few nf-core pipelines:

• Using strict syntax causes template to raise an error when setting boolean options on CLI nf-core/tools#4100

[bentsherman]

It is a consequence of the strict syntax and the params block: https://nextflow.io/docs/latest/migrations/25-10.html#deprecations

When strict syntax is enabled, the legacy CLI type casting is disabled, so as to not preempt the params block if you are using it. And strict syntax is now enabled by default on latest edge

So you have a few options:

• disable strict syntax
• re-enable the legacy CLI type casting
• migrate to params block
• explicitly cast params to desired type e.g. params.flag as Boolean

[scwatts]

Thanks for the response, and this makes sense. Also wanted to add this behaviour is seen with the param block too (see below)

Example with `params` block (click to show)

params {
  boolean_flag = false
}

workflow {
  println "boolean_flag: ${params.boolean_flag} (${params.boolean_flag.getClass()})"
}

$ NXF_VER=26.02.0-edge nextflow run ./main.nf

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

Launching `./main.nf` [soggy_lamport] revision: bf8411e4ca

boolean_flag: false (class java.lang.Boolean)

$ NXF_VER=26.02.0-edge nextflow run ./main.nf --boolean_flag

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

Launching `./main.nf` [mad_cori] revision: bf8411e4ca

boolean_flag: true (class java.lang.String)

[scwatts]

Thinking this through further, the only approach I can see working for Boolean params provided on the CLI when strict syntax is enabled is to cast the param from String to Boolean

Though this would require using an additional variable (or cast each time it is needed) as params can't be changed after they are set. Is there a better way to handle this?

[bentsherman]

@scwatts you need to declare the parameter as type Boolean:

params {
  boolean_flag: Boolean
}

workflow {
  println "boolean_flag: ${params.boolean_flag} (${params.boolean_flag.getClass()})"
}

In latest edge, you don't need to specify the default value of false because it will do that automatically for booleans.

As for your second question, I think the intended solution is to migrate to the params block once you start using the strict syntax at runtime. Unfortunately it's difficult to keep both old and new behaviors and have them play well together

[scwatts]

Explicitly declaring parameter type in the params block solves for my use case, nice approach, and thank you!

[scwatts]

Admittedly, I spent a few minutes having some confusion between the distinction of the script params block v. the config params scope; only the former can be used for type declarations

The full solution for my use case (where the config params scope is the primary way to define parameters and set defaults) is to use both:

nextflow.config

params {
  boolean_flag = false
}

main.nf

params {
  boolean_flag: Boolean
}

workflow {
  println "boolean_flag: ${params.boolean_flag} (${params.boolean_flag.getClass()})"
}

Execution output (click to show)

Both are of Boolean type as expected 🎉

Default value

$ NXF_VER=26.03.0-edge nextflow run ./main.nf

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

Launching `./main.nf` [stupefied_poincare] revision: 9e2f869a72

boolean_flag: false (class java.lang.Boolean)

Set on CLI

$ NXF_VER=26.03.0-edge nextflow run ./main.nf --boolean_flag

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

Launching `./main.nf` [tender_bell] revision: 9e2f869a72

boolean_flag: true (class java.lang.Boolean)

Edited to use correct terminology wrt the two params definitions with clarifications below

[bentsherman]

To be clear, the params config scope is not legacy or deprecated, it's still the primary way to define config params. The best practice is:

• if a param is used in the script, declare it in the script params block
• if a param is used in the config (and not in a closure like ext / publishDir), declare it in the config params scope

[scwatts]

Thank you for clarifying, I've corrected the terminology in my comment above to avoid confusing anyone else reading along

I don't have a full understanding of the purpose / goal the script params block is trying to achieve (e.g. why not allow types in the config params scope). Is there documentation that I can read about this and also best practices / use-cases?

[bentsherman]

It probably could be documented better. Here are some relevant docs for now:

• https://nextflow.io/docs/latest/workflow.html#parameters
• https://nextflow.io/docs/latest/tutorials/static-types.html#migrating-pipeline-parameters

In general, we're trying to take these language updates one step at a time. I'd like to see how people use the bits that we've added so far, then we can add more things as needed.

We could add type annotations for config params, but I'm not sure if we want to go in that direction yet or not. For now, it seems like the config param type can usually be inferred from the default value

[VasLem]

It is a consequence of the strict syntax and the params block: https://nextflow.io/docs/latest/migrations/25-10.html#deprecations

When strict syntax is enabled, the legacy CLI type casting is disabled, so as to not preempt the params block if you are using it. And strict syntax is now enabled by default on latest edge

So you have a few options:

• disable strict syntax
• re-enable the legacy CLI type casting
• migrate to params block
• explicitly cast params to desired type e.g. params.flag as Boolean

@bentsherman the option of explicitly casting params also does not work, example:

test.nf:

params.flag = true

workflow {
    if (params.flag as Boolean) {
        println "Flag is true"
    } else {
        println "Flag is false"
    }
}

nextflow run ./test.nf --flag false

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

Launching `./test.nf` [curious_brattain] revision: d85be9e7ae

Flag is true

Also, same result when I have --flag True or --flag 0 . I tried to use the automatic static type conversion conversion from Nextflow server, but nothing happened to my script.

How to activate the legacy CLI type casting? There is no relevant documentation in the cli section

[bentsherman]

@VasLem looks like I was mistaken -- 'false' as Booleanstill evaluates totrue`. You actually have to convert the param to a string:

params.flag.toString() == 'true'

// or
params.flag.toString().toBoolean()