A community effort to collect a curated set of analysis pipelines built using Nextflow.

nf-core

Is there some way to arbitrarily set/pass an env variable to a (nf-core module) process?

I think there's an ‘env’ input for processes 

That requires patching/writing it that way. What I was after is a way to set one dynamically without needing to patch

Like this?
```env {
    // Set TMPDIR for all modules
    TMPDIR      = "\$PWD"
}```
Goes into your modules.config

<https://docs.seqera.io/nextflow/reference/config/env|docs.seqera.io/nextflow/reference/config/env>

That’s for all modules though, and gets set at the workflow start.
Basically there is an `nf-core` module for which you can override behaviour, but only by an env var, and it needs to be set dynamically per-sample. I wanted to try and avoid patching the module, but I think maybe I can’t

maybe with some creative closure in the env block?

since it’s for tasks, it would make sense it works under the process scope

Maybe you could export the environment variable in a `beforeScript` directive?

And make sure it's in the container env whitelist if using `beforeScript` as that's executed outside the container.

Sorry for being late to the party, but `beforeScript` works fine for running something on your system. If it’s for a module/pipeline, though - it’s wrong. That’s because it’s something commonly needed to deal with locally (e.g. for acquiring a container runtime, or whatnot) and can be expected to be overwritten.

Can you give an example of what you mean Pontus? I don’t understand why something could expect to be overwritten here.

Trivial: `module load apptainer` is required at many HPC sites.

Ah, like our nf-core configs. We’d be overriding the `beforeScript` there. However given it’s a custom config we would just have to include whatever was in the config `beforeScript` as well as whatever `env` we wanted to set as well right?

I don’t think I follow that, but there’s no way I can see it scaling for each institutional config to support each nf-core module feeling up to doing weird stuff.

Again, if it’s for running at your site - not a problem.

If it’s for something ending up in a nf-core pipeline others would be expected to be able to run, fix the module (either by patching it locally or the nf-core module).

I think you’re just suggesting I should PR the module if it’s something others want as opposed to a rare edge-case I am working around for now?

And I will probably PR the module long-term but it may end up being only a temporary issue

Yes, unless it’s a really special case or supporting it needs to be rather ugly, I’d PR the module.