Repository files navigation

The aim of devtools is to make package development easier by providing Rfunctions that simplify and expedite common tasks.RPackages is a book based around this workflow.

# Install devtools from CRANinstall.packages("devtools")# Or the development version from GitHub:# install.packages("pak")pak::pak("r-lib/devtools")

All devtools functions accept a path as an argument, e.g.load_all("path/to/mypkg"). If you don't specify a path, devtools willlook in the current working directory - this is a recommended practice.

• load_all() simulates installing and reloading your package, loading R codeinR/, compiled shared objects insrc/ and data files indata/. Duringdevelopment you would usually want to access all functions (even un-exportedinternal ones) soload_all() works as if all functions were exported in thepackageNAMESPACE.

• document() updates generated documentation inman/, file collation andNAMESPACE.

• test() reloads your code withload_all(), then runs alltestthat tests.

• test_coverage() runs test coverage on your package withcovr. This makes it easy to see what parts of yourpackage could use more tests!

• install() reinstalls the package, detaches the currently loaded versionthen reloads the new version withlibrary(). Reloading a package is notguaranteed to work: see the documentation forunload() for caveats.

• build() builds a package file from package sources. You can use it to builda binary version of your package.

• install_* functions install an R package:

  • install_github() from GitHub
  • install_gitlab() from GitLab
  • install_bitbucket() from Bitbucket
  • install_url() from an arbitrary url
  • install_git() andinstall_svn() from an arbitrary git or SVN repository
  • install_local() from a local file on disk
  • install_version() from a specific version on CRAN

• update_packages() updates a package to the latest version. This worksboth on packages installed from CRAN as well as those installed from any oftheinstall_* functions.

• check() updates the documentation, then builds and checks the package locally.
• check_win_release(),check_win_devel(), andcheck_mac_release() checka package usingwin-builder orhttps://mac.r-project.org/macbuilder/submit.html.
• release() andsubmit_cran() handle the mechanics of CRAN submission withor without, respectively, (re)-running lots of local checks.

R package development can be intimidating, however there are now a number ofvaluable resources to help!

1. R Packages is a book that gives a comprehensive treatment of all common partsof package development and uses devtools throughout.

   • The first edition is no longer available online, but it is still in print. Note that it has grown somewhat out of sync with the current version of devtools.
   • A second edition that reflects the current state of devtools, plus new topics such as package websites and GitHub Actions, is available athttps://r-pkgs.org and in paperback format.
   • TheWhole Game andPackage structure chaptersmake great places to start.

2. Posit Community - packagedevelopmentis a great place to ask specific questions related to package development.

3. rOpenSci packages hasextensive documentation on best practices for R packages looking to becontributed to rOpenSci, but also very useful general recommendationsfor package authors.

4. There are a number of fantastic blog posts on writing your first package, including

   • Writing an R package from scratch - Hilary Parker
   • How to develop good R packages - Maëlle Salmon
   • Making your first R package - Fong Chun Chan
   • Writing an R package from scratch - Tomas Westlake

5. Writing RExtensions isthe exhaustive, canonical reference for writing R packages, maintained bythe R core developers.

devtools started off as a lean-and-mean package to facilitate local packagedevelopment, but over the years it accumulated more and more functionality.devtools has undergone aconsciousuncouplingto split out functionality into smaller, more tightly focussed packages. Thisincludes:

• testthat: Writing and running tests(i.e.test()).

• roxygen2: Function and package documentation(i.e.document()).

• remotes: Installing packages (i.e.install_github()).

• pkgbuild: Building binary packages(including checking if build tools are available) (i.e.build()).

• pkgload: Simulating package loading (i.e.load_all()).

• rcmdcheck: Running R CMD check andreporting the results (i.e.check()).

• revdepcheck: Running R CMD check onall reverse dependencies, and figuring out what's changed since the last CRANrelease (i.e.revdep_check()).

• sessioninfo: R session info (i.e.session_info()).

• usethis: Automating package setup (i.e.use_test()).

Generally, you would not need to worry about these different packages, becausedevtools installs all of them automatically. You will need to care, however, ifyou're filing a bug because reporting it at the correct place will lead to aspeedier resolution.

You may also need to care if you are trying to use some devtools functionalityin your own package or deployed application. Generally in these cases itis better to depend on the particular package directly rather than depend on devtools,e.g. usesessioninfo::session_info() rather thandevtools::session_info(),orremotes::install_github() vsdevtools::install_github().

However for day to day development we recommend you continue to uselibrary(devtools) to quickly load all needed development tools, just likelibrary(tidyverse) quickly loads all the tools necessary for data explorationand visualization.

Please note that the devtools project is released with aContributor Code of Conduct. By contributing to this project, you agree to abide by its terms.