Description of feature
Nextflow supports typed params blocks, and this will likely become mandatory at some point.
Time to introduce it for this pipeline (as well as magmap and metatdenovo -- I think Ampliseq has already transitioned)?
A parallel issue with more detail, written for metatdenovo, is nf-core/metatdenovo#478.
Reproducing the core argument here, adapted to phyloplace.
The problem
A boolean parameter cannot be turned off from the command line.
--save_domtblout false and --save_domtblout=false both arrive as the string 'false', which is truthy in Groovy, so any if ( params.save_domtblout ) check downstream stays true even when the user explicitly asked for false.
There is no warning, and "type": "boolean" in nextflow_schema.json does not coerce it.
The bare form --save_domtblout correctly sets true, so the asymmetry is easy to miss: turning a boolean off from the command line, when a config file or profile already turned it on, simply does not work.
A related failure mode is that a mistyped parameter name is accepted in silence -- --save_domtblot (missing the second t) sets a new, unread parameter instead of erroring.
phyloplace currently has 7 boolean params (save_domtblout, plaintext_email, monochrome_logs, validate_params, help_full, show_hidden, version) out of ~36 total in nextflow_schema.json.
Typed parameters fix both
Nextflow's typed params block coerces the value against the declared type:
params {
save_domtblout: Boolean = false
}Measured on Nextflow 26.04.6 (see nf-core/metatdenovo#478 for the full table): --save_domtblout false correctly yields the Boolean false, and an invalid value (--save_domtblout maybe) becomes a hard compile-time error instead of a silent surprise.
Cost: it requires Nextflow >= 26.04
Under the currently-declared minimum (nextflowVersion = '!>=25.10.4' in nextflow.config), a typed params block does not compile at all.
Adopting this therefore means raising the minimum Nextflow version.
(In metatdenovo#478 this was framed as a major-release decision, but that reflected metatdenovo's own release timing -- work was already heading towards a major version there. There's no nf-core-wide rule tying a Nextflow version bump to a major release; for phyloplace it's fine to include in 2.2.0.)
Scope
~36 parameters in nextflow_schema.json / nextflow.config. Mechanical but pipeline-wide.
Fits the convention this pipeline already follows (see repo docs): main.nf passes plain values into workflows/phyloplace.nf through its take: block rather than letting anything downstream read params.* directly. Typed declarations at the entry point are the natural companion to that.
Open question worth settling first
Typed params create a second source of truth alongside nextflow_schema.json, which nf-schema still validates against.
Types and defaults would have to be kept in sync in two places, and drift between them would be invisible until someone hits it.
Worth checking before starting whether nf-core lint has, or plans, a rule that reconciles the two -- and if not, whether a small check of our own belongs in the PR.
Enriched with help from Claude Code, based on the parallel writeup in nf-core/metatdenovo#478.
Description of feature
Nextflow supports typed
paramsblocks, and this will likely become mandatory at some point.Time to introduce it for this pipeline (as well as magmap and metatdenovo -- I think Ampliseq has already transitioned)?
A parallel issue with more detail, written for metatdenovo, is nf-core/metatdenovo#478.
Reproducing the core argument here, adapted to phyloplace.
The problem
A boolean parameter cannot be turned off from the command line.
--save_domtblout falseand--save_domtblout=falseboth arrive as the string'false', which is truthy in Groovy, so anyif ( params.save_domtblout )check downstream stays true even when the user explicitly asked forfalse.There is no warning, and
"type": "boolean"innextflow_schema.jsondoes not coerce it.The bare form
--save_domtbloutcorrectly setstrue, so the asymmetry is easy to miss: turning a boolean off from the command line, when a config file or profile already turned it on, simply does not work.A related failure mode is that a mistyped parameter name is accepted in silence --
--save_domtblot(missing the secondt) sets a new, unread parameter instead of erroring.phyloplace currently has 7 boolean params (
save_domtblout,plaintext_email,monochrome_logs,validate_params,help_full,show_hidden,version) out of ~36 total innextflow_schema.json.Typed parameters fix both
Nextflow's typed
paramsblock coerces the value against the declared type:params { save_domtblout: Boolean = false }Measured on Nextflow 26.04.6 (see nf-core/metatdenovo#478 for the full table):
--save_domtblout falsecorrectly yields the Booleanfalse, and an invalid value (--save_domtblout maybe) becomes a hard compile-time error instead of a silent surprise.Cost: it requires Nextflow >= 26.04
Under the currently-declared minimum (
nextflowVersion = '!>=25.10.4'innextflow.config), a typedparamsblock does not compile at all.Adopting this therefore means raising the minimum Nextflow version.
(In metatdenovo#478 this was framed as a major-release decision, but that reflected metatdenovo's own release timing -- work was already heading towards a major version there. There's no nf-core-wide rule tying a Nextflow version bump to a major release; for phyloplace it's fine to include in 2.2.0.)
Scope
~36 parameters in
nextflow_schema.json/nextflow.config. Mechanical but pipeline-wide.Fits the convention this pipeline already follows (see repo docs):
main.nfpasses plain values intoworkflows/phyloplace.nfthrough itstake:block rather than letting anything downstream readparams.*directly. Typed declarations at the entry point are the natural companion to that.Open question worth settling first
Typed params create a second source of truth alongside
nextflow_schema.json, whichnf-schemastill validates against.Types and defaults would have to be kept in sync in two places, and drift between them would be invisible until someone hits it.
Worth checking before starting whether nf-core lint has, or plans, a rule that reconciles the two -- and if not, whether a small check of our own belongs in the PR.
Enriched with help from Claude Code, based on the parallel writeup in nf-core/metatdenovo#478.