--- title: "BiocCheck: Ensuring Bioconductor package guidelines" output: BiocStyle::html_document: toc: true vignette: > % \VignetteIndexEntry{BiocCheck: Ensuring Bioconductor package guidelines} % \VignetteEngine{knitr::rmarkdown} % \VignetteEncoding{UTF-8} --- # `BiocCheck` Summary ```{r,include=TRUE,results="hide",message=FALSE,warning=FALSE} library(BiocCheck) ``` `BiocCheck` encapsulates _Bioconductor_ package guidelines and best practices, analyzing packages and reporting three categories of issues: * **ERROR**. This means the package is missing something critical and it cannot be accepted into _Bioconductor_ until the issue is fixed. (`BiocCheck` will continue past an `ERROR`, thus it is possible to have more than one, but it will exit with an error code if run from the OS command line.) * **WARNING**. These issues almost always need to be addressed before the package is added to _Bioconductor_. In the weeks leading up to a _Bioconductor_ release we will ask package authors to fix these issues. * **NOTE**: Not necessarily something bad, just something we wanted to point out. package authors don't need to take action on these, but they can. # Using `BiocCheck` `BiocCheck` is meant to run within R on a directory containing an R package, or a source tarball (`.tar.gz` file): ```{r eval=FALSE} BiocCheck("") ``` `BiocCheck` takes options which can be seen with `?BioCheck`. Note that the `--new-package` option is turned on in the Single Package Builder (SPB) during the new package submission process. # When should `BiocCheck` be run `BiocCheck` should always be run after `R CMD check`. Note that `BiocCheck` is not a replacement for `R CMD check`; it is complementary. It should be run after `R CMD check` completes successfully. `BiocCheck` can also be run via [GitHub Actions](https://docs.github.com/en/actions), a continuous integration system on GitHub. This service allows automatic testing of R packages in a controlled build environment. See the `r Biocpkg("biocthis")` package for more details. # Installing `BiocCheck` `BiocCheck` should be installed as follows: ```{r, eval = FALSE} if (!require("BiocManager")) install.packages("BiocManager") BiocManager::install("BiocCheck") ``` # Interpreting `BiocCheck` output Actual `BiocCheck` output is shown below in **bold**. ## Dependency Checks **Checking Package Dependencies...** Can be disabled with `--no-check-dependencies`. **Checking if other packages can import this one...** * Checks to make sure that there will be no import problems if another package imports your package (`ERROR`). **Checking to see if we understand object initialization....** * Reports if it can't figure out how objects were initialized (`NOTE`). ## Deprecated Package Checks **Checking for deprecated package usage...** Can be disabled with `--no-check-deprecated`. At present, this looks to see whether your package has a dependency on the `multicore` package (`ERROR`). Our recommendation is to use [BiocParallel][7.1]. Note that 'fork' clusters do not rpovide any gain from parallelizing code on Windows. Socket clusters work on all operating systems. Also checks `Deprecated` Packages currently specified in release and devel versions of Bioconductor (`ERROR`). [7.1]: https://bioconductor.org/packages/BiocParallel ## Remotes Usage Check **Checking for remote package usage...** Can be disabled with `--no-check-remotes` Bioconductor only allows dependencies that are hosted on CRAN or Bioconductor. The use of `Remotes:` in the DESCRIPTION to specify a unique remote location is not allowed. ## LazyData Usage Check **Checking for 'LazyData: true' usage...** For packages that include data, we recommend not including `LazyData: TRUE`. This rarely proves to be a good thing. In our experience it only slows down the loading of packages with large data (`NOTE`). ## Version Checks Can be disabled with `--no-check-version-num` and `--no-check-R-ver`. **Checking version number...** * **Checking for version number mismatch...** Checks that the package version specified in your package tarball (if you are checking a tarball) matches the value of the `Version:` field in your `DESCRIPTION` file. If it doesn't, it usually means you did not build the tarball with `R CMD build`. (`ERROR`) * **Checking new package version number...** Checks that the pre-release version for an potential _Bioconductor_ package uses a `99` 'y' version in the `x.y.z` versioning scheme (`ERROR`). Package versions starting with a non-zero value will get flagged with a warning. Typical new package submissions start with a zero 'x' version (e.g., `0.99.*`; `WARNING`). This is only done if the `--new-package` option is supplied. An 'x' nonzero will only be accepted if the package was pre-released or published under such a case. * **Checking version number validity...** Checks for a valid version, that format is correct and that version number is appropriate for this version of _Bioconductor_ (`ERROR`). * **Checking R Version dependency...** If you specify an R version in the `Depends:` field of your `DESCRIPTION` file, `BiocCheck` checks to make sure that the R version specified matches the version currently used in _Bioconductor_. This helps to prevent mixing of Bioconductor release and devel versions (esp. when R versions differ) which is a frequent source of confusion and errors (`NOTE`). For more information on package versions, see the [Version Numbering HOWTO][3]. [3]: http://www.bioconductor.org/developers/how-to/version-numbering/ ## Package and File Size Check Can be disabled with `--no-check-pkg-size` and `--no-check-file-size`. * **Checking package size** Checks that the package size meets _Bioconductor_ requirements. The current package size limit is 5 MB for Software packages. Experiment Data and Annotation packages are excluded from this check. This check is only run if checking a source tarball. (ERROR) * **Checking individual file sizes** The current size limit for all individual files is 5 MB. (WARNING) It may be necessary to remove large files from your Git history; see [Remove Large Data Files and Clean Git Tree][3.1] [3.1]: http://bioconductor.org/developers/how-to/git/remove-large-data/ ## biocViews Checks These can be disabled with the `--no-check-bioc-views` option, which might be useful when checking non-_Bioconductor_ packages (since biocViews is a concept unique to _Bioconductor_). **Checking biocViews...** Can be disabled with `--no-check-bioc-views` * **Checking that biocViews are present...** Checks that a `biocViews` field is present in the DESCRIPTION file (`ERROR`). * **Checking package type based on biocViews** Gives an indication if the package is identified as a Software, Annotation, Experiment, or Workflow package. * **Checking for non-trivial biocViews...** Checks that biocViews are more specific than the top-level terms Software, AnnotationData, or ExperimentData (`ERROR`). * **Checking biocViews validity...** Checks for valid views and displays invalid ones. Note that biocViews are case-sensitive (`WARNING`). * **Checking that biocViews come from the same category...** Checks that all views come from the same parent (one of Software, AnnotationData, ExperimentData) (`WARNING`). * **Checking for recommended biocViews...** Uses the `recommendBiocViews()` function from `biocViews` to automatically suggest some biocViews for your package. More information about biocViews is available in the [Using biocViews HOWTO][4]. [4]: http://www.bioconductor.org/developers/how-to/biocViews/ ## Build System Compatibility Checks The _Bioconductor_ Build System (BBS) is our nightly build system and it has certain requirements. Packages which don't meet these requirements can be silently skipped by BBS, so it's important to make sure that every package meets the requirements. Can be disabled with `--no-check-bbs` **Checking build system compatibility...** * **Checking for blank lines in DESCRIPTION...** Checks to make sure there are no blank lines in the DESCRIPTION file (`ERROR`). * **Checking if DESCRIPTION is well formatted...** Checks if the DESCRIPTION can be parsed with read.dcf (`ERROR`) * **Checking Description: field length...** Checks that the Description field in the DESCRIPTION file has a minimum * number of characters (`WARNING` if less than 50) * number of words (`WARNING` if less than 20) * number of sentences (`NOTE` if less than 3) * **Checking for whitespace in DESCRIPTION field names...** Checks to make sure there is no whitespace in DESCRIPTION file field names (`ERROR`). * **Checking that Package field matches dir/tarball name...** Checks to make sure that `Package` field of DESCRIPTION file matches directory or tarball name (`ERROR`). * **Checking for Version field...** Checks to make sure a `Version` field is present in the DESCRIPTION file (`ERROR`). * **Checking for valid maintainer...** Checks to make sure the DESCRIPTION file has a valid `Authors@R` field which resolves to a valid `Maintainer` (`ERROR`). A valid `Authors@R` field consists of: * A valid R object of class `person`. * Only one person with the `cre` (creator) role. * That person must have a syntactically valid email address. * That person must have either `family` or `given` name defined. * (optional) A syntactically valid ORCID ID, results in note if not. ## DESCRIPTION checks * **Checking License: for restrictive use...** Checks to make sure that the License: in the DESCRIPTION file does not restrict use, e.g., to academic-use only (`ERROR`). Licenses are compared to the database provided at `file.path(R.home("share)", "licenses", "license.db"))`. Licenses not listed in the database are flagged with a `NOTE` indicating that restrictive use status cannot be determined. A `NOTE` is also generated if the `License:` field is malformed, or the database cannot be located. * **Checking for pinned package versions...** Ensures that maintainers are not indicating a specific dependency version using `==` in the `DESCRIPTION` file (`ERROR`). ## NAMESPACE checks Can be disabled with `--no-check-namespace` **Checking DESCRIPTION/NAMESPACE consistency...** `BiocCheck` detects packages that are imported in NAMESPACE but not DESCRIPTION, or vice versa, and provides an explanation of how to fix this (`ERROR`). **Checking for namespace import suggestions...** If the package `codetoolsBioC` is installed, `BiocCheck` will run it to see if it has suggestions for the "Imports" section of your package NAMESPACE. ## .Rbuildignore checks * **Checking .Rbuildignore...** ensures that the 'tests' folder is not accidentally added to the `.Rbuildignore` file (`ERROR`). `codetoolsBioC` is an experimental package that is not presently available via `BiocManager::install()`. It is available from our [Subversion repository][7] with the credentials readonly/readonly. Output of codetoolsBioC is printed to the screen but `BiocCheck` does not label it ERROR, WARNING, or NOTE. [7]: https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC ## BiocCheck output folder check * **Checking for stray BiocCheck output folders...** ensures that the `.BiocCheck` folder byproduct when running `BiocCheck(".")` locally does not get included in the package directory (`ERROR`). ## Vignette Checks Can be disabled with `--no-check-vignettes`. **Checking vignette directory...** * Checks that the `vignettes` directory exists (`ERROR`). * Checks that the `vignettes` directory only contains vignette sources *(*.Rmd, *.Rnw, *.Rrst, .Rhtml, *.Rtex) (`ERROR`). * Checks whether, while checking a directory (not a tarball), vignette sources exist in inst/doc (`ERROR`). * Checks that vignetteBuidler/vignetteEngine are listed in, minimally, Suggests field of DESCRIPTION file (`WARNING`) * Checks that vignetteBuilder in DESCRIPTION and VignetteEngine in vignette are compatible (`ERROR`) * Checks whether vignette title is still using template value (`WARNING`) * Checks wheher the number of `eval=FALSE` chunks is more than 50% of the total (`WARNING`). * Checks whether the global vignette code option is set to `eval=FALSE`. The majority of vignette code is expected to be evaluated (`WARNING`) * Checks for any legacy `BiocInstaller` code (`WARNING`) * Checks that vignette code contains `sessionInfo()` or `session_info()` for reproducibility (`NOTE`). * Checks that evaluated vignette code does not invoke package installation functions (`ERROR`). **Checking whether vignette is built with 'R CMD build'...** Only run when `--build-output-file` is specified. Analyzes the output of `R CMD build` to see if vignettes are built. It simply looks for a line that starts: * creating vignettes ... If this line is not present, it means `R` has not detected that a vignette needs to be built (`ERROR`). If you have vignette sources yet still get this message, there could be several causes: * Missing or invalid `VignetteBuilder` line in the `DESCRIPTION` file. * Missing or invalid `VignetteEngine` line in the vignette source. See `knitr`'s [package vignette][1] page, or the [Non-Sweave vignettes][2] section of "Writing R Extensions" for more information. [1]: http://yihui.name/knitr/demo/vignette/ [2]: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dSweave-vignettes ## Checking Install or Update Package Calls in R code Can be disabled with `--no-check-library-calls` and `--no-check-install-self`. * **Checking library calls...** (`NOTE`) Check for use of functions that install or update packages. This list currently includes the use of `install`, `install.packages`, `update.packages` or `biocLite`. * **Checking for library/require of *(your package name)*...** (`ERROR`) It is not necessary to call `library()` or `require()` on your own package within code in the R directory or in man page examples. In these contexts, your package is already loaded. ## Coding Practices Checks Can be disabled with `--no-check-coding-practices`. **Checking coding practices...** Checks to see whether certain programming practices are found in the R directory. * We recommend that `vapply()` be used instead of `sapply()`. Problems arise when the `X` argument to `sapply()` has length 0; the return type is then a `list()` rather than a vector or array. (`NOTE`) * We recommend that `seq_len()` or `seq_along()` be used instead of `1:...`. This is because the case `1:0` creates the sequence `c(1, 0)` which may be an unexpected or unwanted result (`NOTE`). * Single colon typos are checked for when a user inputs 'package:function' instead of using double colons ('::') to import a function (`ERROR`). * Users should not download data from external hosting platforms. This means avoiding references to major platforms such as GitHub, GitLab, and BitBucket. For the same reason we do not import GitHub packages, external data can be unstable and not well maintained. Maintainers should re-use data already available in Bioconductor or contribute an ExperimentHub, AnnotationHub or similar package (`ERROR`). * A package should not download files at the time of loading or attaching i.e., using `library`. Using `download.file` and `download` should be avoided and when found, an `ERROR` will be emitted. * `paste` and `paste0` function calls within signaling functions such as `message`, `warning`, and `stop` are redundant and should be avoided (`NOTE`). `paste` calls with the `collapse` argument are ignored. * When notifying users, `message` should be used. When `cat` and `print` are used, users will get a note saying that these should only be used in show methods for classes (`NOTE`). * `message`, `warn*`, and `error` keywords should not be included in signal condition functions: `message`, `warning`, and `stop`. This is redundant and should be avoided (`NOTE`). * It is favorable to use the assignment arrow ('<-') over the equals assignment ('=') for clarity in the code and legibility. Any use of the `=` will be flagged with a `NOTE`. * **Checking for T...** **Checking for F...** It is bad practice to use `T` and `F` for `TRUE` and `FALSE`. This is because `T` and `F` are ordinary variables whose value can be altered, leading to unexpected results, whereas the value of `TRUE` and `FALSE` cannot be changed (`WARNING`). * Avoid class membership checks with `class()` / `is()` and `==` / `!=`. Developers should use `is(x, 'class')` for S4 classes. (`WARNING`) * Use `system2()` over `system()`. 'system2' is a more portable and flexible interface than 'system'.(`NOTE`) * Use of `set.seed()` in R code. The `set.seed` should not be set in R functions directly. The user should always have the option for the set.seed and know when it is being invoked. (`WARNING`) **Checking parsed R code in R directory, examples, vignettes...** `BiocCheck` parses the code in your package's R directory, and in evaluated man page and vignette examples to look for various symbols, which result in issues of varying severity. * **Checking for direct slot access...** `BiocCheck` checks for direct slot access (via `@` or `slot()`) to S4 objects in vignette and example code. This code should **always** use accessors to interact with S4 classes. Since you may be using S4 classes (which don't provide accessors) from another package, the severity is only `NOTE`. But if the S4 object is defined in your package, it's **mandatory** to write accessors for it and to use them (instead of direct slot access) in all vignette and example code (`NOTE`). * **Checking for browser()...** `browser()` causes the command-line R debugger to be invoked, and should not be used in production code (though it's OK to wrap such calls in a conditional that evaluates to TRUE if some debugging option is set) (`WARNING`). * **Checking for install()...** The programmatic use of `install()` calls is bad practice. A separation between analysis and configuration tasks keeps code modular and reproducible (`ERROR`). * **Checking for <<-...** Non-local assignment using `<<-` is bad practice. It can over-write user-defined symbols, and introduces non-linear paths of evaluation that are difficult to debug (`NOTE`). * **Checking for Sys.setenv calls...** Packages should not modify system environment variables with the `Sys.setenv` function (`ERROR`). * **Checking for suppressWarnings/Messages...** The excessive use of `suppressWarnings` and `suppressMessages` is problematic as it usually indicates a larger underlying issue with the fragility of the package codebase (`NOTE`). ## Function length checking Can be disabled with `--no-check-function-len`. **Checking function lengths...** `BiocCheck` prints an informative message about the length (in lines) of your five longest functions (this includes functions in your R directory and in evaluated man page and vignette examples). If there are functions longer than 50 lines, `BiocCheck` outputs (`NOTE`). You may want to consider breaking up long functions into smaller ones. This is a basic refactoring technique that results in code that's easier to read, debug, test, reuse, and maintain. ## man page checking Can be disabled with `--no-check-man-doc`. **Checking man page documentation...** * Checking for canned comments in man pages It can be handy to generate man page skeletons with `prompt()` and/or RStudio. These skeletons contain comments that look like this: %% ~~ A concise (1-5 lines) description of the dataset. ~~ `BiocCheck` asks you to remove such comments (`NOTE`). * Every man page must have a non-empty `\value` section. (`ERROR`) * man page examples examples **Checking exported objects have runnable examples...** `BiocCheck` looks at all man pages which document exported objects and lists the ones that don't contain runnable examples (either because there is no `examples` section or because its examples are tagged with `dontrun` or `donttest`). Runnable examples are a key part of literate programming and help ensure that your code does what you say it does. * Checks that at least 80% of man pages must have runnable examples (`ERROR`). * Checks that, if more than 80% of the man pages have runnable examples, but some are still missing, `BiocCheck` lists the missing ones and asks you to add runnable examples to them (`NOTE`). * Check the usage of `dontrun` or `donttest`. Use of these functions is not recommended and shoud be justified (`NOTE`). If exception is made the recommended usage is to use donttest over dontrun (`NOTE`) as donttest requires valid R code. ## NEWS checks Can be disabled with `--no-check-news`. **Checking package NEWS...** `BiocCheck` looks to see if there is a valid NEWS file either in the 'inst' directory or in the top-level directory of your package, and checks whether it is properly formatted (`NOTE`). The location and format of the NEWS file must be consistent with `?news`. Meaning the file can be one of the following four options: * `inst/NEWS.Rd` * `./NEWS.md` * `./NEWS` * `inst/NEWS` NEWS files are a good way to keep users up-to-date on changes to your package. Excerpts from properly formatted NEWS files will be included in _Bioconductor_ release announcements to tell users what has changed in your package in the last release. In order for this to happen, your NEWS file must be formatted in a specific way; you may want to consider using an `inst/NEWS.Rd` file instead as the format is more well-defined. Malformatted NEWS file outputs `WARNING`. More information on NEWS files is available in the help topic `?news`. ## Unit Test Checks Can be disabled with `--no-check-unit-tests`. **Checking unit tests...** We strongly recommend unit tests, though we do not at present require them. For more on what unit tests are, why they are helpful, and how to implement them, read our [Unit Testing HOWTO][5]. [5]: http://www.bioconductor.org/developers/how-to/unitTesting-guidelines/ At present we just check to see whether unit tests are present, and if not, urge you to add them (`NOTE`). **Checking skip_on_bioc() in tests...** Can be disabled with `--no-check-skip-bioc-tests`. Finds flag for skipping tests in the bioconductor environment (`NOTE`) ## Formatting checks Can be disabled with `--no-check-formatting`. **Checking formatting of DESCRIPTION, NAMESPACE, man pages, R source, and vignette source...** There is no 100% correct way to format code. These checks adhere to the [_Bioconductor_ Style Guide][8] (`NOTE`). [8]: http://www.bioconductor.org/developers/how-to/coding-style/ We think it's important to avoid very long lines in code. Note that some text editors do not wrap text automatically, requiring horizontal scrolling in order to read it. Also note that R syntax is very flexible and whitespace can be inserted almost anywhere in an expression, making it easy to break up long lines. These checks are run against not just R code, but the DESCRIPTION and NAMESPACE files as well as man pages and vignette source files. All of these files allow long lines to be broken up. The output of this check includes the first 6 offending lines of code; see more with `BiocCheck:::checkFormatting("path/to/YourPackage", nlines=Inf)`. There are several helpful packages that can be used for formatting of R code to particular coding standards such as [formatR][formatR] and [styler][styler] as well as the "Reformat code" button in [RStudio Desktop][RStudio]. Each solution has its advantages, though [styler][styler] works with `roxygen2` examples and is actively maintained. You can re-format your code using [styler][styler] as shown below: ```{r reformat_code, eval = FALSE} ## Install styler if necessary if (!requireNamespace("styler", quietly = TRUE)) { install.packages("styler") } ## Automatically re-format the R code in your package styler::style_pkg(transformers = styler::tidyverse_style(indent_by = 4)) ``` If you are working with [RStudio Desktop][RStudio] use also the "Reformat code" button which will help you break long lines of code. Alternatively, use [formatR][formatR], though beware that it can break valid R code involving both types of quotation marks (`"` and `'`) and does not support re-formatting `roxygen2` examples. In general, it is best to version control your code before applying any automatic re-formatting solutions and implement unit tests to verify that your code runs as intended after you re-format your code. [formatR]: https://cran.r-project.org/package=formatR [styler]: https://cran.r-project.org/package=styler [RStudio]: https://rstudio.com/products/rstudio/download/ ## Duplication checks * **Checking if package already exists in CRAN...** This can be disabled with the `--no-check-CRAN` option. A package with the same name (case differences are ignored) cannot exist in CRAN (`ERROR`). * **Checking if new package already exists in _Bioconductor_...** Only run if the `--new-package` flag is turned on. A package with the same name (case differences are ignored) cannot exist in _Bioconductor_ (`ERROR`). ## bioc-devel Subscription Check **Checking for bioc-devel mailing list subscription...** This only applies if `BiocCheck` is run on the _Bioconductor_ build machines, because this step requires special authorization. This can be disabled with the `--no-check-bioc-help` option. * Check that the email address in the Maintainer (or Authors@R) field is subscribed to the bioc-devel mailing list (`ERROR`). All maintainers must subscribe to the bioc-devel mailing list, with the email address used in the DESCRIPTION file. You can subscribe [here][9]. [9]: https://stat.ethz.ch/mailman/listinfo/bioc-devel ## Support Site Registration Check **Checking for support site registration...** * Check that the package maintainer is register at our [support site][10] using the same email address that is in the `Maintainer` field of their package `DESCRIPTION` file (`ERROR`). This can be disabled with the `--no-check-bioc-help` option. The main place people ask questions about _Bioconductor_ packages is the support site. Please [register][11] and then include your package name in the list of watched tags. When a question is asked and tagged with your package name, you'll get an email. * Package name is in support site watched tags is now a requirement. [10]: https://support.bioconductor.org [11]: https://support.bioconductor.org/accounts/signup/ # `BiocCheckGitClone` `BiocCheckGitClone` provides a few additional _Bioconductor_ package checks that can only should be run on a open source directory (raw Git clone) NOT a tarball. Reporting similarly in three categories as discussed above: * **ERROR**. * **WARNING**. * **NOTE**. # Using `BiocCheckGitClone` `BiocCheckGitClone` is meant to run within R on a directory containing an R package: ```{r eval=FALSE} library(BiocCheck) BiocCheckGitClone("packageDir") ``` # Installing `BiocCheckGitClone` Please see previous Installing `BiocCheck` section. # Interpreting `BiocCheckGitClone` output Actual `BiocCheckGitClone` output is shown below in **bold**. ## Bad File Check **Checking valid files** There are a number of files that should not be Git tracked. This check notifies if any of these files are present (`ERROR`) The current list of files checked is as follows: ``` hidden_file_ext = c(".renviron", ".rprofile", ".rproj", ".rproj.user", ".rhistory", ".rapp.history", ".o", ".sl", ".so", ".dylib", ".a", ".dll", ".def", ".ds_store", "unsrturl.bst", ".log", ".aux", ".backups", ".cproject", ".directory", ".dropbox", ".exrc", ".gdb.history", ".gitattributes", ".gitmodules", ".hgtags", ".project", ".seed", ".settings", ".tm_properties") ``` These files may be included in your personal directories but should be added to a `.gitignore` file so they are not Git tracked. ## Description Check **Checking DESCRIPTION** Default R CMD build behavior will format the DESCRIPTION file; After this occurs, it is hard to determine certain aspects of the original DESCRIPTION file. An example would be how the Authors and Maintainers are specified. The DESCRIPTION file is therefore checked in its raw original form. * **Checking if DESCRIPTION is well formatted** The DESCRIPTION file must be properly formatted and able to be read in with `read.dcf()` in order to function properly on the Bioconductor build machines. This check attempts to `read.dcf("DESCRIPTION")` and throws an ERROR if mal-formatted. (`ERROR`) * **Checking for valid maintainer** While in the past using the Author and Maintainer fields were acceptable, R has moved towards using the `Authors@R` standard for listing package contributors. This checks that Authors@R is utilized and that there are no instances of Author or Maintainer in the DESCRIPTION (`ERROR`) ## CITATION checks **Checking that CITATION file is correctly formatted** `BiocCheck` tries to read the provided `CITATION` file (i.e. not the one automatically generated by each package) with `readCitationFile()` - this is expected to be in the `INST` folder (`NOTE`). `readCitationFile()` needs to work properly without the package being installed. Most common causes of failure occur when trying to use helper functions like packageVersion() or packageDate() instead of using meta$Version or meta$Date. See [R documentation](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#CITATION-files) for more information. # Expanding `BiocCheck` Contributions to `BiocCheck` are welcome and encouraged through pull requests. Please adhere to the Pull Request template when submitting your contributions. # SessionInfo {-} ```{r sessionInfo} sessionInfo() ```