New feature
DSL2 enables the inclusion of modules, which is a great improvement.
I was wondering if we could go one step further and think of a public "module registry". Think of it as "PyPI for nextflow". I know you turned down "remote modules" in #1376, but a registry would be different in that it
- it would be versioned,
- stored at a central place, ensuring that published modules are not arbitrarily removed,
- would ensure consistent documentation of inputs/outputs of the modules.
This is all about re-using code and avoiding code duplication.
Usage scenario
I want to build a new pipeline that re-uses some standard stuff (e.g. RNAseq alignment) and then does sth custom.
Instead of re-implementing (or copying over and thereby duplicating) a process running STAR I could just, e,g.
and then use the process/workflow in the pipeline
Suggest implementation
The basic building blocks would be:
- A database to store modules
- A website to browse modules
- An API nextflow uses to download modules
- A command-line tool to push modules
I am aware that this is a project by itself and probably out-of-scope for the time being, but I think it's worth keeping in mind.
New feature
DSL2 enables the inclusion of modules, which is a great improvement.
I was wondering if we could go one step further and think of a public "module registry". Think of it as "PyPI for nextflow". I know you turned down "remote modules" in #1376, but a registry would be different in that it
This is all about re-using code and avoiding code duplication.
Usage scenario
I want to build a new pipeline that re-uses some standard stuff (e.g. RNAseq alignment) and then does sth custom.
Instead of re-implementing (or copying over and thereby duplicating) a process running
STARI could just, e,g.and then use the process/workflow in the pipeline
Suggest implementation
The basic building blocks would be:
I am aware that this is a project by itself and probably out-of-scope for the time being, but I think it's worth keeping in mind.