5 Wrapping it all into a package

I believe Hilary Parker’s post on making an R package from scratch is the seminal reference text for this activity. I’ve seen it attributed all over the internet, and as promised, it’s a tremendously simple and straightforward step-by-step guide.

I did run into a few hiccups along the way, due to my complete inexperience with roxygen. For future reference, or for anyone in a similar boat, here are some notes based on bugs and fixes I discovered:

  1. All documentation code begins with #', not the single #.
  2. You have to include #'@export in the documentation of every function if you want it to be available to use in the package.
  3. I had issues when I included a space between the last documentation line and the first line of the function, and also when @export wasn’t the last line of my documentation. I’m not sure if this is truly necessary, but I’m superstitious enough to keep doing it this way.

For example, the bit between my documentation and my function looks like this:

#' ...(more documentation above)
#'@export
skrrrahh <- function(sound=26, expr = NULL) {

Not like this:

#' @export 
#' @params sound expr 
#' 


skrrrahh <- function(sound=26, expr = NULL) {

  1. If any of the functions rely on other packages, you have to @import them for the function to work properly. If the packages you’re importing are huge, and you only want to import certain functions, you can do that as well.

  2. Generally, especially if this is your first package, it’s best to shoot for a minimum viable product. MVPs may not include all the examples or links to other documentation that you will eventually want your code to have, but they get it up and running as quickly as possible. You can add additional documentation later. It’s also easier to troubleshoot issues if you’re building a package step-by-step. When you’ve got a ton of well-documented functions, it will be harder to identify the source of the problem if your package fails to build properly.