Checklist stores it configuration as a checklist.yml file. create_package(), setup_package() and setup_source() generate a default file. If you need to allow some warnings or notes, you need to update the configuration.

write_checklist(x = ".", package = TRUE)

Arguments

x

Either a Checklist object or a path to the source code. Defaults to ..

package

Logical indication if checklist.yml refers to an R package. Defaults to TRUE.

Details

First run x <- checklist::check_package() or x <- checklist::check_source(). These commands run the checks and store the CheckList object in the variable x. Next you can store the configuration with checklist::write_checklist(x). This will first list any existing allowed warnings or notes. For every one of them, choose whether you want to keep it or not. Next, the function presents every new warning or note which you may allow or not. If you choose to allow a warning or note, you must provide a motivation. Please provide a sensible motivation. Keep in mind that checklist.yml stores these motivations in plain text, so they are visible for other users. We use the yesno() function to make sure you carefully read the questions.

Caveat

When you allow a warning or note, this warning or note must appear. Otherwise you get a "missing warning" or "missing note" error. So if you fix an allowed warning or note, you need to rerun checklist::write_checklist(x) and remove the old version.

If you can solve a warning or note, then solve it rather than to allow it. Only allow a warning or note in case of a generic "problem" that you can't solve. The best example is the checking CRAN incoming feasibility ... NOTE New submission which appears when checking a package not on CRAN. That is should an allowed note as long as the package is not on CRAN. Or permanently when your package is not intended for CRAN.

Do not allow a warning or note to fix an issue specific to your machine. That will result in an error when checking the package on an other machine (e.g. GitHub actions).

See also