Updating dev guide

docs/developer.md

@@ -40,13 +40,32 @@ Some aspects of this code base are controlled by config files. These are:
 This pipeline imports a few functions into the nextflow files from lib/ - mostly to keep the actual pipeline code a bit cleaner/more readable. For example, 
 the `--help` command line option can be found in lib/WorkflowMain.groovy. Likewise, you could use this approach to do some basic validation of your inputs etc. 
 
+## Bioconda/biocontainers
+
+By design, modules should provide software as either conda environment or container. See existing modules for how that can be achieved. 
+
+```
+conda 'bioconda::multiqc=1.19'
+container "${ workflow.containerEngine == 'singularity' && !task.ext.singularity_pull_docker_container ?
+    'https://depot.galaxyproject.org/singularity/multiqc:1.19--pyhdfd78af_0' :
+    'quay.io/biocontainers/multiqc:1.19--pyhdfd78af_0' }"
+```
+
+What does this do? Basically, if conda is enabled as software provider, the specified package will be installed into a process-specific environment. Else, a container is pulled - where the source depends on whether you run Docker (native Docker image) or e.g. Singularity (dedicated singularity image).
+
+We normally use Bioconda as the source for software packages; either directly via conda or through containers that are built directly from Bioconda. You'll not that each Bioconda package lists the matching Biocontainer link. For convenience, it is recommended to provide links to the native Biocontainer Docker container as well as the singularity version hosted by the Galaxy team under [https://depot.galaxyproject.org/singularity/](https://depot.galaxyproject.org/singularity/).
+
+There are two situations where this approach will not work (directly). One is the use of multiple software packages in one pipeline process. While this can be done for conda-based provisioning by simply providing the name of multiple packages, it does not work for pre-built containers. Instead, you need a so-called "mulled" container; which are built from two or more Bioconda packages - described [here](https://github.com/BioContainers/multi-package-containers). Sometimes you can be lucky and find existing mulled containers that do what you need. Else - see the description above. 
+
+If mulling containers is not an option, you can also refer to github actions and have the pipeline built its own mulled container. For that, see below. 
+
 ## Github workflows
 
-Github supports the automatic execution of specific tasks on code branches, such as the automatic building and pushing of Docker containers. To add github workflows to your repository, rename the folder `dot_github` to `.github` and adjust the files therein accordingly (name of pipeline, docker repo etc).
+Github supports the automatic execution of specific tasks on code branches, such as the automatic linting of the code base or building and pushing of Docker containers. To add github workflows to your repository, place them into the sub-directory `.github/workflows`. 
 
 ### Docker containers
 
-In order to automatically push Docker containers, you must add your docker username and API token as secrets to your repository (DOCKERHUB_USERNAME and DOCKERHUB_TOKEN). Secrets can be created under Settings/Secrets and Variables/Actions. Of course, you also need to have an account on Dockerhub and generate a permanent token.  
+In order to automatically push Docker containers, you must add your docker username and API token as secrets to your repository (DOCKERHUB_USERNAME and DOCKERHUB_TOKEN). Secrets can be created under Settings/Secrets and Variables/Actions. Of course, you also need to have an account on Dockerhub and generate a permanent token.  The relevant workflow actions are included in `dot_github/workflows`. These will read the `Dockerfile` from the root of this repository, import environment.yml (if you wish to install conda packages into the container), build the whole thing and push the container to an appropriate dockerhub repository 
 
 ## How to start
 

docs/installation.md

@@ -7,7 +7,7 @@ range of such infrastructures, including Slurm, LSF and SGE - but also Kubernete
 
 Please see conf/lsh.config for an example of how to configure this pipeline for a Slurm queue.
 
-All software is provided through Docker containers - this requires for your compute system to run either Docker or Singularity (more common on HPC systems). Details on how to specify singularity as your container engine are provided in the config file for our lsh system (lsh.config).
+All software is provided through either Conda environments or Docker containers. Consider a Docker-compatible container engine if at all possible (Docker, Singularity, Podman). Conda environments are built on the fly during pipeline execution and only for a given pipeline run, which tends to slow things down quite a bit. Details on how to specify singularity as your container engine are provided in the config file for our lsh system (lsh.config).
 
 With this information in place, you will next have to create an new site-specific profile for your local environment in `nextflow.config` using the following format:
 

docs/usage.md

@@ -1 +1,4 @@
 # Usage information
+
+## Basic execution
+

modules/samtools/dict/main.nf

@@ -16,7 +16,6 @@ process SAMTOOLS_DICT {
     path("versions.yml"), emit: versions
 
     script:
-    assembly = meta.assembly
     dict = fasta.getBaseName() + '.dict'
 
     """

nextflow.config

@@ -6,6 +6,7 @@ params {
 
     help            = false
 
+    logo            = "${baseDir}/assets/pipelinelogo.png"
     run_name        = null
 
     plaintext_email = false
@@ -23,7 +24,7 @@ params {
 
 }
 
-// DEV update name and version of pipeline, author name and URL
+// TODO: update name and version of pipeline, author name and URL
 manifest {
     name = "marchoeppner/pipeline"
     version = "0.0"