Provide way to provide all optional parameter to each module

[jfy133]

Description of feature

Either by:
distinc tparameters on a one-to-one relationship (harder to maintainer), but ensures no breakage

[alxndrdiaz]

@jfy133 I need to fully understand what needs to be updated/added:

Module options are usually defined in conf/modules.config. But there might be use-cases where a global parameter is required, this is defined in nextflow_schema.json. For instance malt_sequencetype=DNA OR Protein could have a one-to-one relationship with the MALT parameter --sequenceType DNA OR --sequenceType Protein in the conf/modules.config or another config file. I guess they did something similar here: sarek/conf/modules/.

Let me know if this makes sense or not.

[jfy133]

So I don't like the further splitting up of module configs into multiple places, it makes it harder for users to then find.

What I mean by the 'either by', is either we have a 'lenient' (simple for us, but risk of breakage for users) or 'strict' (more work for us, but more guaruntee it works) approach:

Lenient

User:

--ganon_build_params "--mode smallest --filter-size 256 --max-fp 0.2"

Dev:

process {
    withName: GANON_BUILD {
        ext.args = {"${param.ganon_build_params}"}
    }
}

There will indeed be a few cases this is a bit more tricky when indeed like you said there are some hardcoded stuff, but I know people like Nicolas v. N., Matthias d.S, and Maxime G. (will ping if we go this route) all do some fancy stuff to 'parse' these parameter strings to pluck out specific elements.

Strict

User:

--ganon_build_mode smallest --ganon_build_filtersize 256 --ganon_build_maxfp 0.2"

Dev:

process {
    withName: GANON_BUILD {
        ext.args = [ "--mode ${param.ganon_build_mode}", "--filter-size ${param.ganon_build_filtersize}", "--max-fp ${ganon_build_maxfp}" ].trim().join(" ")
    }
}

More work for us, and we would then have to theroetically add one pipeline parameter for each of the parameters of the tool itself, which could be many. We could instead just offer a core set of ones that we think are most important for each build tool, and slow add more at user request, but I'm certainly not an expert in all of these tools to know what are the most important flags etc...

[jfy133]

I'm sort of leaning towards lenient and if it becomes problematic with lots of bug reports from peoples we can switch in a v2 to the strict mode...

[jfy133]

Does that help with the two options @alxndrdiaz ?

The question more related to your original one is whether to expose the global parameters as options for everything (and those gos traight into modules.conf, or be more picky.

[alxndrdiaz]

Does that help with the two options @alxndrdiaz ?

The question more related to your original one is whether to expose the global parameters as options for everything (and those gos traight into modules.conf, or be more picky.

Ok. It is clear now. I will do the "lenient" mode and will let you know when the PR is ready for review.