My workflow for reproducible analysis

workflow_reproducible_analysis.Rmd

---
title: "Workflow for Reproductible Analysis"
author: "Matthias Grenié"
date: "8 mars 2017"
output: word_document
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```

When I want to analyze specific data for a project and make it reproducible I follow a certain number of steps, to ensure the analysis is fully reproducible (you could obtain the same results re-running the whole workflow). I followed those steps when designing the [analyses](https://github.com/Rekyt/mammal_funrar) of a North and Central American dataset.


## 0. Use git and Github (or Bitbucket or Gitlab)

To ensure you will be able to track all the versions of the code you're using, you can use [git](http://git-scm.com/). It's handy especially when used with a remote repository system like [Github](https://github.com), [Bitbucket](http://bitbucket.org/) or a locally-installed instance of [Gitlab](https://about.gitlab.com/), in particular to sync code between different computers or work with other collaborators on the same code.

If you also want to version data files that are generally bigger than Github or Bitbucket limits. Consider using [Git Large File Storage system (git-lfs)](https://git-lfs.github.com/).

## 1. Use `remake`

I discovered the [`remake` R package](https://github.com/richfitz/remake) recently. It is basically a tool to build reproducible workflows directly into R. Everything is based on a YAML file that describes the dependencies between objects and what commands should be run to create those objects.

Here's an excerpt of the `remake.yml` file from the [mammal project](https://github.com/Rekyt/mammal_funrar):

```yaml
packages:
    - dplyr
    - ggplot2

sources:
    - scripts

targets:
    all:
        depends:
        - README.md

    # Download data
    dryad_dataset:
        command: download_lawing_2015()
        packages: rdryad

    # Treat trait and presence-absence matrix
    raw_mammal_traits:
        command: read.csv("data/dryad.116171/DryadArchive/Traits.csv")
        depends: dryad_dataset
```

The first lines indicate which packages have to be loaded, then the to load the R files in the `scripts` folder.

To described the dependencies you have to write rules to make `targets` (similar to GNU Make).

remake then runs the command you specify to build the target which are then accessible using the `fetch()` function in `remake`. For example, the trait data.frame built by the above-mentionaed remake.yml file would be available using:

```r
remake::fetch("raw_mammal_traits")
```
and you can store it momentarily as a regular R object:
```r
raw_traits = remake::fetch("raw_mammal_traits")
```

## 2. Automatically Download data from data repositories

In this case, as shown above in the `remake.yml` file, I used the awesome [`rdryad`](https://github.com/ropensci/rdryad) package to directly download data from a Dryad repository. By using `remake` I made sure the workflow would run only after having downloaded the datafile.


## 3. Design your functions and split functions across files

For each target defined in the `remake.yml` file you can use specific functions. Each part of the analysis consisted of a series of functions, in separate files in the `scripts` folder. I had:

```
1-download_data.R
2-subset_data.R
3-functional_rarity.R
4-render_readme.R
```
the sequential naming scheme helps to show that those files are sequentially used by the remake workflow.


## 4. Get a diagram of the dependencies in the analysis

With remake and well-defined dependencies you can get a graph of the current dependencies using:
```
remake::diagram()
```
as in (https://github.com/Rekyt/mamm_funrar/blob/master/README_figs/README-unnamed-chunk-1-1.png)


## 5. Sit back and watch the analysis run

When you defined everything you just have to type:
```
remake::make()
```
and remake will build everything that needs to be updated, depending on changes in R files or input datasets.


## 6. Get a DOI for the code on Github

I recently found out that some journals don't accept zipfiles as supplementary material. But you may want to still cite your code in the paper.

Github announced they partenered with [Zenodo](https://zenodo.org/) to issue DOI to code. Everything is (well) described on the [Github help page](https://help.github.com/articles/referencing-and-citing-content/). Basically you have to log into Zenodo using your Github account then authorize Zenodo, then select a project you would like to archive in Zenodo, to finalize the process you have to create a release of the code in Github, which will have a specific DOI assigned by Zenodo. See for example versions of the `funrar` package: [v1.0.1](https://doi.org/10.5281/zenodo.154729) and [v1.0.2](https://zenodo.org/record/168055).