It would be handy to have some of the processes that YAVSAP uses outsourced into Nextflow DSL2 modules in a separate repo(s).
More Info
Context
YAVSAP has a lot of overlap with https://github.com/ksumngs/v-met (in fact, it was originally a fork of v-met), and a number of the tools used are identical. If we outsource the common tools, then we will be reducing redundancy.
Alternatives
nf-core does this via their cli tool. All of their modules are in the same repo, and then their cli tool manually pulls the modules and commits them to the individual pipeline repository. This works for them, but it would be better to use a git submodule approach in my mind.
Possible implementation
Tools that are common to both
Sample ingest
Nanofilt
Trimmomatic
Kraken2
KrakenTools
Seqtk Merge
Seqtk fasta
BLAST
Each of these tools come with a default set of parameters and the container definition. I propose that each of these modules have a sidecar nextflow.config file that can be included in the main config file.
Summary
It would be handy to have some of the processes that YAVSAP uses outsourced into Nextflow DSL2 modules in a separate repo(s).
More Info
Context
YAVSAP has a lot of overlap with https://github.com/ksumngs/v-met (in fact, it was originally a fork of v-met), and a number of the tools used are identical. If we outsource the common tools, then we will be reducing redundancy.
Alternatives
nf-core does this via their cli tool. All of their modules are in the same repo, and then their cli tool manually pulls the modules and commits them to the individual pipeline repository. This works for them, but it would be better to use a
git submoduleapproach in my mind.Possible implementation
Tools that are common to both
Each of these tools come with a default set of parameters and the container definition. I propose that each of these modules have a sidecar
nextflow.configfile that can beincluded in the main config file.