Get started

This section just provides a general overview of the guidelines for the structure of the source code directory and the naming conventions. The most important guidelines are detailed in the Add a process section.

Important

It is important to note that the geniac repository relies on the structure of the geniac template while the geniac template could work without the geniac repository (provided that you generate manually the missing Config files for the different nextflow profiles).

It means also that this documentation explains how the geniac template works with the geniac repository.

All the examples shown in the documentation are taken from the geniac demo. You can clone this repository and reproduce what is presented.

Prerequisites

The following software are required:

To use the containers, at least one of the following software is required:

Test geniac on the geniac-demo pipeline

As a quick start, you can try the geniac demo pipeline as follows:

# Create the geniac conda environment (use conda >= 4.12.0)
export GENIAC_CONDA="https://raw.githubusercontent.com/bioinfo-pf-curie/geniac/release/environment.yml"
wget ${GENIAC_CONDA}
conda env create -f environment.yml
conda activate geniac

# Prepare the working directory for the use case
export WORK_DIR="${HOME}/tmp/myPipeline"
export INSTALL_DIR="${WORK_DIR}/install"
export GIT_URL="https://github.com/bioinfo-pf-curie/geniac-demo.git"

# Initialization of a working directory
# with the src and build folders
geniac init -w ${WORK_DIR} ${GIT_URL}
cd ${WORK_DIR}

# Check the code
geniac lint

# Install the pipeline
geniac install . ${INSTALL_DIR}

# Test the pipeline with the multiconda profile
geniac test multiconda

Start a new repository

The best way to initiate your repository is to create a new Git project from the geniac template. Indeed, geniac expects that the repository contains specific folders and files that are already set up in the template. However, you can use geniac on an existing repository and you can follow the procedure described in the FAQ.

Naming convention

Variables

Use camelCase, for example outDir = './results'.

Channels

Use camelCase and add the suffix Ch, for example fastqFilesCh.

Files

Prefer camelCase (whenever possible as some tools expect specific pattern such as MultiQC like _mqc suffix), for example someScript.sh.

For the scripts you develop and that are accessible in the bin/ use the prefix ap (analysis pipeline), for example apMyscript.sh. This prefix makes it possible to distinguish the scripts you personally developed from those you retrieved from third parties.

Environment variables

Use snake_case and upper case, for example MY_GLOBAL_VAR = "someValue".