Fix class not resolved in param declaration

[VasLem]

How to deal with "undefined" variables, that are loaded by nextflow.config or exist in the environment?

Is there a way to silence these errors? If so it would be nice to have a quick fix above for ignoring that error at a line basis.

[bentsherman]

Implicit environment variables like this will not be supported in the future because it is impossible to tell between an environment variable and a regular variable. We may add some alternative syntax in the future, but for now you can do System.getenv(REF_ROOT) to avoid the error

https://nextflow.io/docs/latest/vscode.html#excluded-syntax

[VasLem]

Alright, thanks, I see, I tried to make this change, but I receive a "System is not defined" issue now.

This error appears only for "System" commands called outside workflow and process context, it seems it works okay otherwise.
I understand that silencing an error is not a good practice if you are planning to have a strictly formal language specification. Also, I was not aware of that page you referenced, it clears out several issues I had regarding Groovy and Nextflow compliance.

[VasLem]

Another thing popped up after I implemented the change, when I define an env var within a nextflow.config profile, it doesn't seem to be picked up by System.getenv within a process, I am left with null...

[bentsherman]

I am seeing the issue with System.getenv in a param declaration, I will look into it

Regarding the env config scope, those variables are exposed to the task environment, not the pipeline script

[VasLem]

The thing is that until now, the env vars were picked just fine by the script as well... Wasn't this not intended? If I just leave the variables as is, without using System.getenv, they work perfectly fine, with the right value given in the config.

[bentsherman]

Interesting, that is not the intention, see the relevant docs here:

https://nextflow.io/docs/latest/reference/config.html#env

Can you share a minimal test case where an env in the config is printed in the script?

[bentsherman]

Actually it was pretty easy to replicate:

env {
    FOO = 'bar!'
}

println "${FOO}"

$ nextflow run test.nf

 N E X T F L O W   ~  version 24.10.0

Launching `test.nf` [shrivelled_almeida] DSL2 - revision: 320593a247

bar!

@pditommaso FYI, it looks like config env settings are exposed in the script?

[VasLem]

(...it would be great to have this non-intended behavior stay as is, changing profiles and having env variables adapt to these changes is really, really helpful 🥹)

[pditommaso]

FYI, it looks like config env settings are exposed in the script?

Not 100% sure it was desired. We may need to review along with the mechanism to access env variables both in config and script files.

Maybe, it could be used env. both to define and access env variables both for tasks and script

[bentsherman]

Maybe, it could be used env. both to define and access env variables both for tasks and script

I was thinking the same, env() would be nicer than System.getenv() and consistent with env() process output

[bentsherman]

The issue with System.getenv() will be fixed in the next patch release. Also, a new env() function will be introduced in Nextflow 24.11.0-edge