If/when you want to go into R packaging in more depth, see Hadley Wickham’s book R Packages.

Part 2. Beyond Basics

How to write print and plot functions for your objects.
A little more Roxygen documentation
Using pkgdown to make a website for your package.
Sharing your package
Sharing on GitHub
Checking your package

Creating print and plot methods for your objects

Make your output an object

littleforecast <- function(data, nyears=10){
  fit <- forecast::auto.arima(data)
  fc <- forecast::forecast(fit, h = nyears)
  ggplot2::autoplot(fc)
  class(fit) <- c("foo", class(fit))
  return(fit)
}

print method

#' Prints foo object
#'
#' prints a foo object returned from littlefunction().
#'
#' @param x foo object
#' @param ... Not used
#' @method print foo
#' @export
print.foo <- function(x, ...) {
  cat("Hello there")
}

plot method

#' Plots foo object
#'
#' Plots foo object.
#'
#' @param x An foo object.
#' @param ... Not used.
#' @method plot foo
#' @export
plot.foo <- function(x, ...) {
  plot(1:10)
}

Roxygen Documentation

roxygen2 (and the the ‘Build and Install’ step) will create the help files that users access with `?function.name.

The same man files are also used to create a package manual, e.g. package help file

And it generates the navigation page for all the documentation

help(package="forecast")

The man files are also used by pkgdown to make a website version of your documentation. Here is an example of a pkgdown-generated webpage for the FIT R package r4MAS.

Set-up

Install the roxygen2 R package.

install.packages("roxygen2")

Set the Project Build Options to use Roxygen

Tools > Project Options… > Build Tools > then check the checkbox “Generate documentation with Roxygen”. Then click “Configure”. Check the box at the bottom for “Install and Restart”.
Make sure your DESCRIPTION file has these lines:

Roxygen: list(markdown = TRUE)
RoxygenNote: <some number>

Basic structure

Roxygen comments with #' are put at the top of your function, in the same file. They have a standard format and standard sections. There is a bit of customization you can do, but the following basic form will cover 95% of your needs. Read this for more details.

#' @title Short title
#'
#' @description 
#' Description should be one paragraph. Put details in details.
#'
#' @details
#' Optional if you want to add more detais.J
#'
#' @param param.name1 Describe all your function arguments
#' @param param.name2 Describe all your function arguments
#'
#' @examples
#' # provide some examples of how to use your function
#' hello()
#'
#' @seealso List relevant other functions [littleforecast()].
#' 
#` @references 
#' List references
#' @export
yourfunction <- function(param.name1, param.name2){}

@title and @description can be left off (not the text, just the @…. part), but title text should be in line 1, then a blank line (#’ only), and then the description text. The only required elements are @title, @description, and @param (defining the function arguments).

@export means that your function is added to your NAMESPACE so is not hidden. Just include this for now.

Add help to `hello()`

First remove the old hello.Rd file from the man folder. That is there because when we created our new package using RStudio’s template, we didn’t select ‘use Roxygen’ so it added a manually created help (i.e. Rd) file for us in the man folder. Now we are going to use Roxygen, so we need to remove that file.

Copy and paste this to the top of hello.r in the R folder. Replace all the comments at the top with these lines.

#' Hello World!
#'
#' Prints a the classic first program greeting. It takes no arguments.
#'
#' @examples
#' hello()
#' @export

To build the documentation, click ‘Install and Restart’ from the Build tab.

Once your package is reloaded (library(MyPackage) appears on the command line), you can type ?hello to get the help info.

Updating the documentation

When you update the documentation or add new documentation, rebuild the help files using the ‘Install and Restart’ button on the Build tab. Note, with the default Project Options, RStudio does not remake the documentation when you click ‘Install and Restart’. You have to change that by going to Tools > Project Options > Build Tools and then clicking ‘Configure’ next to ‘Generate documentation with Roxygen’ and then clicking the box next to ‘Install and Restart’.

Adding references

If you use BibTex you can insert references by citation in your help files.

Create the inst folder if you don’t have one
Within that, create REFERENCES.bib 3 Add refs to that in BibTex format.
Install the Rdpack package
Add Rdpack to Imports in your DESCRIPTION file and add RdMacros: Rdpack to your DESCRIPTION file.
Cite in your Roxygen header using

\insertRef{Waltonetal1998}{MyPackage}

Example of a reference in REFERENCES.bib

@article{Waltonetal1998,
  title={The development and operational application of nonlinear algorithms for the measurement of sea surface temperatures with the NOAA polar-orbiting environmental satellites},
  author={Walton, CC and Pichel, WG and Sapper, JF and May, DA},
  journal={Journal of Geophysical Research: Oceans},
  volume={103},
  number={C12},
  pages={27999--28012},
  year={1998},
  publisher={Wiley Online Library}
}

Add the citation to your Rd file with

\insertRef{Waltonetal1998}{MyPackage}

pkgdown

VRData example pkgdown site.
r4MAS FIT public R package.

Install the packages. I’ll use {usethis} to make things easier.

install.packages("usethis")
install.packages("pkgdown")

Build your package site

usethis::use_pkgdown()
pkgdown::build_site()

Let’s get this up on GitHub using GitHub Pages. Go to Settings on your repo and scroll down to ‘GitHub Pages’.

NOAA branding

The NMFS Fisheries Integrated Toolbox has a branded template that you can use pkgdown template.

GitHub Actions

Remembering to run {pkgdown::build.site()} every time you change code is both a hassle and unnecessary. Today, we use GitHub Actions to do that for us.

These are put in a .github/workflows folder in your GitHub repo. Here is an example.

That looks hard! Oh we don’t write that code. You just copy a template. Talk to someone who uses these to get tips.

Use the NMFS Fisheries Intergrated Toolbox actions
Talk to a local R UG group. NOAA R Users can join the NMFS R UG

Styling your code

You should stick with a uniform style guide to make your code easier to follow. I use the tidyverse style guide with the styler R package. styler has an RStudio Addin which does all the work of styling my code for me. Install the package, restart RStudio, and then go to Tools > Addins > Browse Addins. Scroll down to styler, and select the file(s), you want to style.

Spell-checking all your code. Use an RStudio add-in or {usethis} package.

Checking your package

Just use the RStudio Check in the Build tab. You’ll have many issues (most likely). Plug away at each one until you pass with no errors or warnings. Don’t ignore Notes either. They are sometimes more serious than the errors and warnings.

If R asks you to update packages, and then proceeds to fail at installation because of a warning that a package was built under a later R version than you have on your computer, use

Sys.setenv(R_REMOTES_NO_ERRORS_FROM_WARNINGS=TRUE)

Run Check from the Build tab regularly.

It is best not to put this off too long or else you’ll create a lot more work for yourself as you track down one warning or error after another.
Don’t let yourself suffer trying to figure out what the warnings and errors mean.

Most are simple namespace issues that are easy to fix once you know how. Ask someone who builds packages. The NMFS R UG Group Chat is a good place.

Common errors

Undeclared global functions: You forgot :: somewhere
Undeclared global. That’s either a bug or its the ggplot2 and dplyr problem.
Examples have problems. Note check runs through these alphabetically. Sometimes it can be hard to figure out where the problem was.
- Use dontrun{} to make code that won’t run. Horribly, it can be really hard to actually not run this code, so make sure the code is correct. If you are showing bad code, then you’ll need to comment it out.
- Use donttest{}. It is hard to get this respected when you run check. If you have donttest{} in your examples you’ll need to get some help.

Extras

These are the most common things I run into or want to do with my packages.

Depends versus Imports

@Depends These packages that will be loaded when your package is loaded. So if you have gplot2 in @Depends, like above, then the user automatically can use ggplot2 functions without issuing the command library(ggplot2).

@Imports Are required for the package functions, but the user will not have access to the functions without calling library(...). In your package, you will use :: to access the functions from the packages on the @Imports line. Most of your package dependencies will be here.

To limit the number of headaches that users face when trying to install your package, use as few packages on your @Depends and @Imports lines in DESCRIPTION file as possible. If your package does not need the package to work, then put the package on @Suggests.

I have R packages that are mainly for my personal use. I use the package to make sure I have access to the various packages that I’ll be using. So for example, if I am doing work on my sardine papers, I have set of packages that I use. When I issue the command library(SardineForecast) a bunch of packages are loaded. This makes it handy for me, but all those dependencies makes it a huge hassle to install the package from GitHub for my collaborators (and even a hassle for me to install from GitHub). Huge Hassle. Invariable one of the 15 packages that I need will itself have a dependency that won’t load and then I have to debug that. If I need collaborators, who are on different operating systems and various versions of R to install it, it’s a suffer-fest.

For my MARSS package, I have only 3 non-base dependencies in the @Imports line and nothing on the @Depends line besides R. The imports are KFAS, mvtnorm, and nlme. Then on the @Suggests line, I have a bunch of packages that are used in the vignettes. MARSS is easy to install from GitHub (though it is also hosted on CRAN).

What should you put on your Depends and Imports lines?

First off, when you are starting, don’t worry too much about this. Just add packages that are needed as you work on your functions.

ALWAYS use :: to use functions from other packages in your package functions. Seriously. You will save yourself so many headaches down the road by being able to search for xyzpackage:: to find all that packages functions. Why? Trust me, one day you will want to swap out packages or remove dependencies. Note, this can be a hassle with functions like ggplot() which use functions within their calls and you have to use :: everywhere. Like so
```
ggplot2::ggplot(df) +
   ggplot2::geom_point(ggplot2::aes(gp, y))
```
Arg. Another example is say a GAM call:
```
mgcv::gam(a ~ mgcv::s(b), data=df)
```
But this is just for your package functions. In your scripts, you’d probably use a library() call.
Never ever use library() in a function! Use xyzfunction::function. Sure use library() in your scripts, but never in a package function. When you add a function from a new package to your function, add those packages to @Depends or @Imports in your DESCRIPTION file as you go along.
Every so often check that you don’t have packages on @Depends and @Imports that you don’t use. Just do a Edit > Find in Files… search for xyzpackage:: to find out if you are still using xyzpackage.
How do you know if you forgot a dependency or forgot a :: somewhere? Two ways:
1. Do Session > Restart R to close all your loaded packages. Then load your package with library(yourpackagename) and try your functions. Things will fail if you have a package in @Imports but forgot a :: somewhere.
2. From the Build tab, use More > Check Package. That should show package dependency errors (plus a whole slew of other problems for you to work through).

Styling your code

Writing a vignette

Doing this in RStudio is easy. See rmarkdown vignette chapter and Hadley’s vignette chapter for more info.

Making the vignette

Manually

Make a vignettes folder at the base level (same level as the R folder)
Create a new vignette file from a template. RStudio > File > New > R Markdown > From Template > Vignette
Save in vignettes folder
Change the title in the 2 places in the yaml at the top. ‘yaml’ is between the --- fences.
Add the following 2 lines to your DESCRIPTION file:

Suggests: knitr, rmarkdown
VignetteBuilder: knitr

Or use a helper function:

devtools::use_vignette("my-vignette")

usethis::use_vignette("MyNewPackage")

Testing your vignette

Open your vignette file and click the Knit button.

Getting your vignette to show up

Once you have your vignettes in the vignettes folder, you’l like to be able to build them and have them appear when you type browseVignettes("MyNewPackage"). This will not work. In fact, RStudio seems to actively hinders this workflow.

Vignettes can take a long time to build and by default when R builds a package from source (which is what Install and Restart on the build tab does), it does not re-make your vignettes. You can make RStudio re-make your vignettes in the vignettes folder (if the Rmd file changes) using Tools > Project Options > Build Tools > Generate documentation with Roxygen > Configure and clicking the vignettes check-box. But this will not get your vignettes loaded when you click Install and Restart on the Build tab (browseVignettes() still won’t work).

So how does R know about your vignettes when it is building from source (i.e. from Install and Restart in the Build tab in RStudio)? It needs the vignette files (.Rmd, .R and .html) in the inst/doc folder. How do you get them there? You have to put them there.

That’s easy. I’ll just put them there whenever I change or add vignettes. Unfortunately, the default RStudio default behavior is to delete the whole inst/doc folder whenever you click Check (package) in the Build tab. It’s happening because the default is to use devtools::check() and there is no way to set devtools::check(vignettes=FALSE). To stop RStudio from deleting inst/doc on package checking, uncheck the use devtools package functions if available box. You may also want to add --no-manual to the R CMD Check options box since that is the default for devtools::check().

This is my vignette workflow:

Create the vignette folder and add vignette Rmds to it using the R Markdown vignette template in RStudio.
Create the inst folder in my package at the base level (same level as the R folder).
Edit my vignette Rmd and use the Knit button to preview.
When I am done, run the following code to update the vignette files and copy to the inst/doc folder.

tools::buildVignettes(dir = ".", tangle=TRUE)
dir.create("inst/doc")
file.copy(dir("vignettes", full.names=TRUE), "inst/doc", overwrite=TRUE)

Once your vignette files are in inst/doc, Install and Restart button will add the vignettes to your package and install_github() will have them too.

Careful, RStudio Check in the Build tab will delete the inst/doc folder and not recreate it. So always check that inst/doc not been trashed and uncheck the use devtools package functions checkbox on the Build > More > Configure Build Tools… window. You will most likely also want to add --no-manual to the R CMD check additional options box.

References

If/when you want to go into R packaging in more depth, work through the material from this R package workshop material. You’ve seen much of this material so it should be somewhat familiar. See also Hadley Wickham’s book R Packages. I like this reference too http://www.danieldsjoberg.com/writing-R-packages/#1

NWFSC Math Bio Program, NOAA Fisheries

Week 6. Part 2 Intro to R packages

Part 2. Beyond Basics

Creating print and plot methods for your objects

Make your output an object

print method

plot method

Roxygen Documentation

Set-up

Basic structure

Add help to hello()

Updating the documentation

Adding references

pkgdown

Build your package site

NOAA branding

Sharing your package

Let’s share our package on GitHub

GitHub Actions

Styling your code

Checking your package

Common errors

Extras

Depends versus Imports

Styling your code

Writing a vignette

Making the vignette

Testing your vignette

Getting your vignette to show up

References

Add help to `hello()`