camelCase params duplicated with hypens

[ewels]

Bug report

Expected behavior and actual behavior

When using a param with camelCase, a duplicated copy is made with hyphens (camel-case). I've never noticed this before, but the new @nf-core schema validation now warns about these params as they are unexpected.

Expected behaviour would be to, well, not do this. 😀

Steps to reproduce the problem

params.snake_case = 'foo'
params.camelCase = 'bar'
params.multiCamelCaseParam = 'baz'

println(params)

Program output

$ nextflow run main.nf
N E X T F L O W  ~  version 21.03.0-edge
Launching `main.nf` [elegant_euler] - revision: b5f0bc6361
[snake_case:foo, camelCase:bar, camel-case:bar, multiCamelCaseParam:baz, multi-camel-case-param:baz]

More readable:

• snake_case: foo
• camelCase: bar
• camel-case: bar
• multiCamelCaseParam: baz
• multi-camel-case-param: baz

'cc @KevinMenden @Leon-Bichmann

[pditommaso]

Yes, this was a choice made in the early days, I admin, not one of the best.

[ewels]

What's more confusing is that the nextflow config command doesn't do this, only nextflow run:

nextflow.config:

params {
    snake_case = 'foo'
    camelCase = 'bar'
    multiCamelCaseParam = 'baz'
}

main.nf:

println(params)

$ nextflow config -flat .
params.snake_case = 'foo'
params.camelCase = 'bar'
params.multiCamelCaseParam = 'baz'

$ nextflow run .
N E X T F L O W  ~  version 21.03.0-edge
Launching `./main.nf` [happy_brattain] - revision: ec72fcbcb3
[snake_case:foo, camelCase:bar, camel-case:bar, multiCamelCaseParam:baz, multi-camel-case-param:baz]

This is actually a good thing in our case, as it means that we only need to add a workaround in the pipeline schema validation at run time, and don't need to patch any of the code in nf-core/tools that builds stuff with the output of nextflow config.

Phil

[pditommaso]

I think it should be fixed with a big note in the cli docs

[pditommaso]

Done ebfed09

[ewels]

Thank you!

[awgymer]

I cannot replicate the behaviour of camelCase --> kebab-case, only the reverse.

Did this logic change at some point?

main.nf here contains just println params in the workflow:

nextflow run main.nf --plain test --camelTest camelly --kebab-test kebaby

[plain:test, camelTest:camelly, kebabTest:kebaby, help:false, helpFull:false, showHidden:false]

[bentsherman]

We fixed it a while ago. It will only convert kebab-case to camelCase and not the other way around, and it doesn't save the kebab-case in the params map

[awgymer]

Hmm. Is there some clarification on what should be allowed or possible here (and perhaps what will be in the future if it's planned as a syntax upgrade).

This new situation means that it's still technically possible to define a kebab-cased param, but that it's impossible to define via the cli or the standard config.

Works:

params.'kebab-param' = 'forbidden fruit'

Does not work:

params {
    kebab-param = 'forbidden fruit'
}

params {
    'kebab-param' = 'forbidden fruit'
}

They can be passed in via -params-file still, but cannot be set on the CLI by any method I have found so far.

Should kebab-case params just be considered as fully deprecated at this point?

[bentsherman]

kebab-case params are intended as a CLI shorthand for the equivalent camelCase param. Python's argparse does the same thing but for snake_case instead of camelCase. We might support that in the future once we have the workflow params definition (#5929).

But your example is precisely why we don't bother supporting kebab-case params directly. They can only be defined in the script with obscure syntax, and even this won't work with the upcoming params syntax. Thus they are only supported on the command line or in a params file.