- Do we expect to have more than one tool per step (e.g gridss and svaba): No
- Is there redundancy/dependency in the package parameters. Can parameters be organized into a dependency tree or otherwise hardcoded because they never change?: Yes, need to investigate.
- Do we care about alignment? Should the pipeline be able to start at alignment? No.
- Refactor output channel attribute extraction (21)
- Swich from steps conditionals to cases (8)
- Switch from tools to nodes (13)
- Remove alignment step (3)
- Refactor repetitive declarations (1)
- Swtich from the "step" based conditionals to something more declarative (e.g cases). Having the program run a block of code by checking if the starting step is included in a list of steps is enormously cumbersome, cases should make things more parsimoinous and readable.
- Tools-in-step paradigm could be replaced with ungrouped nodes.
- Use functions for repetitive declarations/imports and hold their required variables in arrays/maps.
- Clean up output channel attribute extraction. Currently very repetitive, could be replaced with functions.
- Cut down on the number of default parameters in the config (possibly at the package level). Packages/processes/workflows shouldn't have so many parameters (see: JaBbA as the worst offendor), it indicates either overparameterization or a dependency tree in the parameter space.
- Add *_create_csv methods for remaining tools to generate samplesheets to start from those tools
- Move parameter specification from nextflow.config to module specific config, then import them into nextflow config. This keeps the process and its parameter configuration tightly coupled--but loses a central interface for modifying all the defaults in one place, which is useful if changing one default would affect defaults in a different parameter.