Make vsc_calcua strict syntax compatible

[nvnieuwk]

This PRs converts the config to the strict syntax.

@pmoris would you mind testing this config on the cluster it is designed for? Please run a test with strict syntax enabled (NXF_SYNTAX_PARSER=v2) and with it disabled (NXF_SYNTAX_PARSER=v1) to ensure backwards compatibility.

Let me know if something's broken 😁

[pmoris]

I'll give it a go (soonTM). Cheers for the update!

[pmoris]

I haven't gotten around to testing or reviewing the changes yet, but I'll allocate some time to do so next week. Thanks for the help in any case!

[pmoris]

OK! I've tested the new config and had to make the following changes:

• Changes param "functions" into dynamic variables.
• Fixes regression: dynamic allocation of resources should be used in single node
  execution mode instead of slurm scheduling mode.
• Use explicit int/str types for dynamic resource allocation to avoid weird behaviour.

After these adjustments, everything seems to work when using either NXF_VER=26.02.0-edge NXF_SYNTAX_PARSER=v2 nextflow run nf-core/demo or NXF_VER=26.02.0-edge NXF_SYNTAX_PARSER=v1 nextflow run nf-core/demo, both in the slurm scheduling and the single node execution modes.

What I'm still unsure about:

• Should all the System.getenv() calls be replaced with env() or will that break things for older versions of nextflow? See https://www.nextflow.io/docs/stable/strict-syntax.html#implicit-environment-variables
• Weird bug related to typing (although I think I've managed to work around it for now)

https://nextflow.slack.com/archives/C02TPSL19UJ/p1774277999098809

I came across a weird behaviour when comparing v1 and v2 strict syntax, where it seems that using the elvis operator on a mix of strings and integers somehow converts str(4) into int(52)

def node_max_cpu = 28

def int max_cpus = node_max_cpu

def slurm_task = '4'
def slurm_node = '4'

max_cpus = slurm_task ?: slurm_node ?: node_max_cpu

println "max_cpus = ${max_cpus} (type: ${max_cpus.class.name})"


└─▶ NXF_VER=26.02.0-edge NXF_SYNTAX_PARSER=v1 nextflow run test.nf
Nextflow 26.03.0-edge is available - Please consider updating your version to it

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

Launching `test.nf` [wise_solvay] revision: 265d31ac18

max_cpus = 52 (type: java.lang.Integer)


└─▶ NXF_VER=26.02.0-edge NXF_SYNTAX_PARSER=v2 nextflow run test.nf
Nextflow 26.03.0-edge is available - Please consider updating your version to it

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

Launching `test.nf` [desperate_cray] revision: 265d31ac18

max_cpus = 4 (type: java.lang.String)

[nvnieuwk]

You also have a third merge conflict at the end of the config, could you resolve this first?

[pmoris]

Ack. That's what I get for not double-checking. Things went awry when I switched between two machines and juggled a git stash.

Added a fixup. You can do a rebase --autosquash before eventually merging to clean up the commit history a bit.

[nvnieuwk]

Looks good to me, feel free to approve and merge if you think this is ready

[pmoris]

There's a bunch of exit statements in the config that the automatic tests seem to have problems with. I guess I could change them into warnings instead?

[nvnieuwk]

Yeah that might be for the best

[pmoris]

To everyone I somehow tagged => ignore this. GH keeps messing with my attempts to rebase/squash instead of merge...

[pmoris]

Seems to work on CalcUA, but some of the tests keep failing even after I removed the system.exit() calls. ! Is it OK if I just ignore them? I think the issue is with other configs, rather than changes we made to this one.

[nvnieuwk]

The test for your config works so feel free to merge :)

[nvnieuwk]

@nf-core-bot fix linting

[pmoris]

The test for your config works so feel free to merge :)

Merging is blocked due to failing merge requirements => isn't that caused by the failing tests?