Addressing Check warnings a) .bib file location and b) refering to data in function

[Mcshaz]

On running R CMD Check I have a few warnings - I am happy to ignore, but I would prefer to address the warnings if possible, and I would appreciate advice on how to best address the warnings.

1. The bibligography file is at the top level, generating the warning:

Non-standard file/directory found at top level:
    'REFERENCES.bib'

Obviously if I add this file to the .Rbuildignore file, my vignettes and Roxygen documentation will not be able to find it. Is there a standard place to put the .bib file to avoid this warning?

2. I have some included .rda files in the data directory - the one in question being named ap3_comorbidity_scores. One of my functions references these data by name:

apache3_comorb <- function(comorbs) {
   <various_code_here...>
        replace_matches(
          .data$comorb,
          ap3_comorbidity_scores
        ),

resulting in the warning

  apache3_comorb: no visible binding for global variable
    'ap3_comorbidity_scores'
  Undefined global functions or variables:
    ap3_comorbidity_scores

The function works well in automated tests , and even when installing the remote from github into a clean project, so the warning appears to be unfounded, but is there a way to address this warning? even placing data("ap3_comorbidity_scores") at the beginning of the function did not change the warning. Do you have thoughts on other way to address this warning?

Thank you very much.

[jdblischak]

@Mcshaz

Obviously if I add this file to the .Rbuildignore file, my vignettes and Roxygen documentation will not be able to find it. Is there a standard place to put the .bib file to avoid this warning?

If it were only required by the vignettes, I'd say move it to vignettes/. But since it's also being used by the Roxygen documentation, then maybe try moving it to inst/. The main downsides of this is that the location of the files in inst/ changes when the package is installed, so this could get tricky. Would you be able to provide an example of how you are accessing REFERENCES.bib in your roxygen comments?

@Mcshaz

The function works well in automated tests , and even when installing the remote from github into a clean project, so the warning appears to be unfounded, but is there a way to address this warning? even placing data("ap3_comorbidity_scores") at the beginning of the function did not change the warning. Do you have thoughts on other way to address this warning?

I was able to reproduce this global variable warning when accessing a data set from within a package function. Some thoughts:

• Since you know where the variable is coming from, the simplest way to suppress that warning would be to add utils::globalVariables("ap3_comorbidity_scores") in a file in R/ (and also add utils to DESCRIPTION)
• Another way to remove the warning is to prefix the variable with the package name, eg pkgname::ap3_comorbidity_scores, though I admit this looks a bit strange
• Think about how you intend for this data to be used and accessed. Is it only for use in internal package functions or do you intend end users of your package to also use it (eg to run examples in your roxygen documentation or vignettes)? Data defined in data/ is intended for the latter use case. If it is internal only, there are other options, which are well-explained in the Data chp of R Packages

[Mcshaz]

Thank you very much @jdblischak

The repository is up at GitHub - mcshaz/icuscoreR: apply ICU scoring systems to patient data using R.

The readme.rmd contains references to the biliography such as calculate the Acute Physiology and Chronic Health Evaluation (APACHE) III score (@Knaus1991-be) and the vignettes have similar (although more) references, although the readme references the bibliography as bibliography: "REFERENCES.bib" and the vignette bibliography: "../REFERENCES.bib", so I swapped these around to reference "vignettes/REFERENCES.bib" in the Readme.rmd file.

As for point 2, I think your suggestion of namespacing these data to the package itself is the option I will choose here. The function is almost the part that exists for the sake of example, with the diagnostic scoring data important to include for reference sake.