Default Fields

• Title: is slightly more explanatory title to your project beyond the package name.
• Version: is not terribly important in this context. I usually leave it at the default. You can read more about R package versioning here.
• Authors: is self explanatory and may be written in plain text, however, it’s strongly suggested that you replace this with the Authors@R: field. This sets the authors and roles in a more programmatic way and establishes emails and roles (author "aut", creator "cre", contributor "ctb", copyright holder "cph").

Authors@R: person("Joshua", "Brinks", email = "jbrinks@isciences.com",
 role = c("aut", "cre"))

• Maintainer: is the package maintainer. Typically the same as the author. Written in plain text followed by the email address: Joshua Brinks <jbrinks@isciences.com>.
• Description: is a comprehensive description of your package functions. I usually include a few sentences for context and functionality.
• License: is the operating license of your package determines the legality of how and whom may use your package. Being this is an article on open science we strongly recommend using a Free or Open Source Software Licence (FOSS) when possible, however, there are several contexts where this simply doesn’t work. There is lots of discussion regarding comparative software licenses on the internet. I suggest you acquire a greater understanding. When possible I implement a GPL3 open source license with usethis.

usethis::use_gpl3_license()

• Encoding: determines your package encoding. Usually a good idea to leave this UTF-8.
• LazyData: determines how the data you embed in your package is loaded when your package is loaded. It’s best to leave this set to true. This ensures that data embedded in your package is only loaded into memory when you call on the dataset. Otherwise any large datasets will use up memory as soon as your package is loaded.
• RoxygenNote: specifies the version of roxygen2 being used to manage your package documentation. It will be updated automatically.

Additional Fields

These are other common fields.

• URL: Any appropriate package or personal website. I usually list the Git pkgdown website here.
• Imports: is a list of packages that your package depends on to carry out its core functions found in the R/ directory. If you have a function in the R/ directory that uses data.table::merge(), dplyr::filter(), and ggplot2::geom_point(), these packages must be listed in the Imports:. This ensures that when your package is installed additional dependencies are also installed. Syntax for the Imports: and Suggests: is:

Imports: data.table,
 dplyr,
 ggplot2

• Suggests: is similar to Imports: but for packages that are used in your vignettes, but not listed as part of your core Imports:. These are typically packages used for your vignettes (rmarkdown, leaflet), but you may also have a package you use for a rare function in the R/ directory that you don’t want to automatically load as a courtesy for your users.
• Remotes: is used to specify packages your package depends on that are not released on CRAN but are available on GitHub or GitLab. The syntax is gitsite::repository.

Remotes: gitlab::dante-sttr/commonCodes,
 gitlab::dante-sttr/untools

The simplest way to add a package dependency is with usethis, although I typically edit the DESCRIPTION file directly.

usethis::use_package("ggplot2")

Here is an example of a completed DESCRIPTION from the duplicator package.

RStudio Build Tools and Roxygen Options interfaces.

Importing data.table and tidyverse Packages

When importing either the data.table or tidyverse packages you must accommodate their special operators and naming conventions (data.table doesn’t need quoted variables in functions) that are not part of base R programming. For tidyverse this refers to the %>% (pipe) operator that comes from the magrittr package. data.table implements several additional operators including c(.N, .I, ':='). If these operators are not addressed your package will kickback warnings and errors when executing build checks. usethis has functions to assist setting these up.

usethis::use_data_table()

usethis::use_pipe()

These functions will adjust your imports section. Additionally, they will both create non function files in your R/ directory (utils-data-table.R and utils-pipe.R). The utils-data-table.R file needs an addendum to handle the special operators. The base file created is:

# data.table is generally careful to minimize the scope for namespace
# conflicts (i.e., functions with the same name as in other packages);
# a more conservative approach using @importFrom should be careful to
# import any needed data.table special symbols as well, e.g., if you
# run DT[ , .N, by='grp'] in your package, you'll need to add
# @importFrom data.table .N to prevent the NOTE from R CMD check.
# See ?data.table::`special-symbols` for the list of such symbols
# data.table defines; see the 'Importing data.table' vignette for more
# advice (vignette('datatable-importing', 'data.table')).
#
#' @import data.table
NULL

As stated you must add the additional line for their operators. I would add the most common.

# data.table is generally careful to minimize the scope for namespace
# conflicts (i.e., functions with the same name as in other packages);
# a more conservative approach using @importFrom should be careful to
# import any needed data.table special symbols as well, e.g., if you
# run DT[ , .N, by='grp'] in your package, you'll need to add
# @importFrom data.table .N to prevent the NOTE from R CMD check.
# See ?data.table::`special-symbols` for the list of such symbols
# data.table defines; see the 'Importing data.table' vignette for more
# advice (vignette('datatable-importing', 'data.table')).
#
#' @import data.table
#' @importFrom(data.table, .N, .I, ':=')
NULL