---
# System prepended metadata

title: Porting FORCE2NXF-Rangeland to nf-core report
tags: [review, porting, earth-sciences]

---

---
title: Porting FORCE2NXF-Rangeland to nf-core report
authors: Maxime Garcia, James A. Fellows Yates, Friederike Hanssen
tags: earth-sciences,porting,review
---

# Report: porting FORCE2NXF-Rangeland to nf-core

The purpose of this document is to evaluate the steps required for the porting of the 'earth sciences' pipeline [_FORCE2NXF-Rangeland_](https://github.com/CRC-FONDA/FORCE2NXF-Rangeland) to nf-core.

## Action Plan

### Critical

1. Start from scratch with nf-core template
2. Containers
    - Ensure tagged releases of FORCE docker container available on dockerhub
    - Check that FORCE on DockerHub is permanent (already has open source plan? Or request moving to quay.io? - i.e. not going to be lost due to the 6month DockerHub limit)
    - Ask permission to put on conda-forge, and put on conda-forge
3. Start writing standalone `force-*` modules
    - Do not include custom bash in nf-core/modules, move to local modules
4. Plan how to make all input files/data files/URLS etc., are completely changeable (remove all hardcodedness)

### Suggestions

4. Investigate moving metadata from paths and into a `meta` map
5. Write local modules for file organisation and config file generation
6. Keep MultiQC - but purely for version reporting

Otherwise follow nf-core template (e.g. parameter locations, )

## Scratch notes

1. Start from nf-core template 
2. Suggestion modules:
    3. Make wget module (or use existing aria2)
    4. Separate custom bash (to local) from tools (official nf-core) 
        5. e.g. processHigher -> local module to make the 'config' file, and this is passed to a `force-higher-level` module with config file + input file as inputs, no making configs within nf-core module (or follow controlFreq)
4. All parameters from `workflow-dsl2.nf`, and modules etc. -> `nextflow.config`
    4. CPU/Time/Memory should be moved outside 
4. Containerisation All modules need to remove container versions
    5. Need to make and use tagged releases
    5. Never 'latest', always specific
    6. Report version used and propagate it outside the module
6. Replace semi-hardcoded folder structures in input data with a `-profile` (e.g. igenomes)
7. Parameterise: all hardcoded files and URLs 