The following checks are currently implemented in the pkgcheck
package. Several of these are by default only shown when they fail;
absence from a resultant checklist may be interpreted to indicate
successful checks.
Ensure that default GitHub branch is not “master”
The $info$git$branch value is taken by default from GitHub as long as
“DESCRIPTION” has a remote URL. It is only taken from local git if not
remote GitHub URL can be identified.`
Check whether all functions have examples.
Check that all functions document their return values.
The reflects a CRAN checks for all new submissions, to ensure that
return values are documented for all functions. This check applies even
to functions which are called for their side effects and return NULL.
Check whether a package has a inst/CITATION file.
“CITATION” files are required for all rOpenSci packages, as documented in our “Packaging Guide. This does not check the contents of that file in any way.
Check whether package has contributor guidelines in a ‘contributing’ file.
A “contributing” file is required for all rOpenSci packages, as documented in our “Contributing Guide.
Check whether the package license is acceptable.
Details of acceptable licenses are provided in the links in our Packaging Guide.
Check for failed lintr checks in the package.
This function runs all available lintr_* checks from the package on
the target package and returns the names of any failed checks.
Check that R directory is flat, with no sub-directories.
Check numbers of package dependencies (‘Imports’)
Check whether the package depends on any obsolete packages for which better alternative should be used.
The list of obsolete packages is given in our Packaging Guide. Some of these are truly obsolete, the use of which raises a red cross in the summary of checks; while others are only potentially obsolete, thus use of which merely raises a note in the detailed check output.
Check whether a package is on CRAN or not.
This does not currently appear in any ‘pkgcheck’ output (that is,
neither in summary or print methods), and is only used as part of
pkcchk_pkgname_available.
Check if authors have ORCID IDs
Check whether any instutitions listed as role = "fnd" have RORs
If >= 10 ‘.Rd’ files, check that ’_pkdown.yml’ has a reference grouping.
Check that package name is available and/or already on CRAN.
For packages which use ‘renv’, check that it is de-activated.
Although we do not generally recommend ‘renv’ for package developement,
packages may use it. They must, however, ensure that renv is
deactivated.
Check that GitHub repository lists an associated website
Check that GitHub repository is not a fork.
Check whether the package contains any useless files like .DS_Store.
Files currently considered “scrap” are:
Check whether all function names are unique.
Uses the database of function names from all CRAN packages associated
with releases of the pkgstats
package.
Check that a package ‘DESCRIPTION’ file lists a valid URL.
Check that a package ‘DESCRIPTION’ file lists a valid URL in the “BugReports” field.
Check if examples use \dontrun{}
This check identifies functions in the package documentation that have
examples using \dontrun{}. The use of \dontrun{} is discouraged by
CRAN and should only be used the example really cannot be executed
(e.g. because of missing additional software, missing API keys, …) by
the user. Instead use methods to run the examples conditionally, such as
with the @examplesIf() roxygen tag.
Check whether all documntation has been generated by ‘roxygen2’
Use of ‘roxygen2’ to generate package documnetation is mandatory for rOpenSci packages, and is described in detail in our Packaging Guide.
Check whether the package contains at least one vignette.
Check that left-assignment operators are used consistently throughout a package.
Left-assign operators recognised by R are: (“=”, “\<-”, “\<\<-”, “:=”), as defined in the main grammar definition. This actually checks the following two conditions:
The := operator is ignored in these checks.
Check that ‘srr’ documentation for statistics pacakges is complete.
Procedures for preparing and submitting statistical packages are
described in our “Stats Dev
Guide”. Statistical packages must
use the ‘srr’ (software review roclets)
package to document compliance with our
statistical standards. This check uses the
srr::srr_stats_pre_submit()
function
to confirm that compliance with all relevant standards has been
documented.
Get all CI badges from a repository, and check that jobs currently pass.
This extracts badges directly from README files. If none are found and a repo is GitHub, then an additional function is called to check CI status directly from GitHub workflow files.
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.