My R Journal

Things I learn along my R programming journey.
Software Engineering

Howard Baek


July 11, 2023

Tips and tricks I learn to program in R.

R package

Demystifying Dependencies

Choose whether package dependency is an “Imports” or a “Suggests” package:

“Imports”: Read Section 11.1 ~ 11.4 from the R Packages book:

“Suggests”: Read Section 11.5 from the R Packages book:

Handy functions

  1. Write roxygen tag into the source code of package: usethis::use_import_from("pkg", "function")
  2. Add package to Imports field of DESCRIPTION: usethis::use_package("pkg")

Submitting to CRAN

First release:

  • usethis::use_news_md() creates a file with “News” items
  • usethis::use_cran_comments() initiates a file to hold submission comments for your package
  • Update instructions on README to install package from Github to from CRAN, in anticipation of your package’s acceptance.
  • Proofread Title: and Desription: fields of DESCRIPTION as they are real hotspots for nitpicking during CRAN’s human review. Read advice given in Section 9.2 of the R Packages book.
  • Check that all exported functions have @returns and @examples
  • Check licenses
  • Review (extra ad-hoc checks that CRAN does that are not checked for by devtools::check())

To keep tabs on what other package maintainers are talking about,

Updating a package already on CRAN:

  • Check current CRAN check results
  • If you have depcreated functions, check Gradual deprecation
  • Update NEWS with changes to the package.
  • Run urlchecker::url_check() and devtools::build_readme()

Always Run No Matter What:

  • devtools::check(remote = TRUE, manual = TRUE)
  • devtools::check_win_devel()
  • rhub::check_for_cran() (There are some bug-related messages, like Skipping checking HTML validation: no command 'tidy' found, Found the following files/directories: NULL or lastMiKTeXException)

Reverse Dependency Check:

Running for the first time: usethis::use_revdep() Then, run revdepcheck::revdep_check(num_workers = 4)

Ready to Submit:

  • Bump the version number in DESCRIPTION
  • devtools::submit_cran(). After a successful upload, you should receive an email from CRAN within a few minutes. This email notifies you, as maintainer, of the submission and provides a confirmation link.
  • At the confirmation link, you are required to re-confirm that you’ve followed CRAN’s policies and that you want to submit the package. If you fail to complete this step, your package is not actually submitted to CRAN!


Google APIs and OAuth 2.0


Google APIs use the OAuth 2.0 protocol for authentication and authorization. To begin, obtain OAuth 2.0 client credentials from the Google Cloud. See this page on getting your own API credentials. Then your client application requests an access token from the Google Authorization Server, extracts a token from the response, and sends the token to the Google API that you want to access.

For an interactive demonstration of using OAuth 2.0 with Google (including the option to use your own client credentials), experiment with the OAuth 2.0 Playground.

Before your application can access private data using a Google API, it must obtain an access token that grants access to that API. A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that an access token permits.

Some requests require an authentication step where the user logs in with their Google account. After logging in, the user is asked whether they are willing to grant one or more permissions that your application is requesting. This process is called user consent.

See this diagram to get an overview of the entire process of calling a Google API.

Further Reading on dealing with OAuth 2.0 in R:


Chunk options

When you knit a R Markdown file with the following code chunks,

Setup code chunk (not shown because include set to FALSE):

knitr::opts_chunk$set(echo = TRUE, comment = ">")
knitr::opts_chunk$get()[c("echo", "comment")]
> $echo
> [1] TRUE
> $comment
> [1] ">"

knitr::opts_chunk$get() shows you the default (global) options.

knitr::opts_current$get()[c("echo", "comment")]
### $echo
### [1] TRUE
### $comment
### [1] "###"

knitr::opts_current$get() shows you the options set in the chunk itself.

The doc gives more details:

Normally we set up the global options once in the first code chunk in a document using opts_chunk$set(), so that all latter chunks will use these options. Note the global options set in one chunk will not affect the options in this chunk itself, and that is why we often need to set global options in a separate chunk.