Summary of recommended packages

[jl5000]

It would be really useful to provide a list of RAP related packages and a visual schematic/process diagram of their usage in the RAP. Including:

Rmarkdown/ knitr
drake
here
renv/packrat
usethis
testthat

[nacnudus]

Related to #64
Pinging @matt-dray who has blogged about drake.

A good next step would be to write an article about one of those things and submit it in a Pull Request.

[matt-dray]

A few thoughts.

First, my understanding is that the RAP companion is effectively 'frozen in time' and new materials should be added to the RAP website (GitHub repo).

Some options for approaching this idea:

• a community-updated list of best-practice packages grouped by purpose
• an exemplar RAP that uses these best-practice packages, as per need simpler examples than eesectors #64
• separate articles on the RAP website about broad themes (like testing) that go into some depth and take account of R and Python (there's already one about dependencies, for example)
• etc

Questions:

• who decides what the best packages are?
• of those, which are the most important?
• which can be used in conjunction?
• what if you can't access certain packages from your organisation?
• should this be separated by coding language?
• etc

Possible package 'groupings' (yours plus a few more as examples):

• package management: {renv}
• communication: {knitr} for compiling R Markdown, {kable} for R Markdown tables, {ggplot2} for visualisation, {pkgdown} to create a 'front-door' for the package
• workflow management: {drake}
• unit testing: {testthat}
• helpers: {here} for avoiding file path woes, {usethis} for easy package setup
• etc

These would be tricky to be put in a process diagram. Some are used at very specific points, while others encompass the entire workflow.

[jl5000]

I think we need to make a clear distinction between packages that specifically enable RAP and those which are just generally recommended. I think ggplot2 falls into the latter, and if we include that, I'm not sure why we don't just include the whole tidyverse. The kable package is another one - is there anything specifically more RAPpy about that than there is with, say gt?

With all the others, things are made quite easy as there is usually one de-facto package most people use (notwithstanding packrat Vs renv, but I think renv is probably going to become that).

I agree with your comments about a process diagram, it is tricky, but I'm still hoping there's a way to create some kind of diagram to illustrate where everything fits.

[matt-dray]

I think we need to make a clear distinction between packages that specifically enable RAP and those which are just generally recommended

Totally agree. {ggplot2}, {kable} and {pkgdown} were thrown in to flesh out the idea of 'groupings' – sets of packages that people have found useful for developing within RAP projects and definitely not intended as essentials.

I forgot to say that a good framework might be to map packages to the 'RAP levels'. Let's not forget that a valid RAP project needn't use any packages whatsoever and that different amounts and combinations of packages become more important as you progress up the levels.