11

I'm currently co-developing an R package using devtools. We use the tidyverse %>% and associated purrr and dplyr packages within our functions.

One of our functions is as follows (edited for clarity):

#' Print `cust_modl` object
#'
#' @param x A `cust_modl` object.
#' @param ... Additional arguments passed to `print.cust_modl()` to print the
#'   object.
#'
#' @method print cust_modl
#' @export
print.cust_modl <- function(x, ...) {

req_var_nms <- x$var %>%
purrr::compact(.x = .) %>%
names(x = .)

comp_var_ind_filt <- req_var_nms %>%
purrr::map(.x = ., .f = ~ purrr::pluck(x$var, .x))

}

This is currently giving an NOTE in our Github Actions devtools::check() as:

print.cust_modl: no visible binding for global variable ‘.’

I understand that this error is due to rlang related issues based on this helpful post. So typically we use @importFrom rlang .data as suggested and ensure that in dplyr we carry the .data$ syntax correctly when referencing columns.

However, it seems that this NOTE was being given by the purrr calls and it is not clear how to correct the rlang import for just the . (rather than the usual more explicit .data call in dplyr).

Could anyone please explain how to correctly adjust R package code for the . as called by tidyverse packages such as purrr? I understand that we can locally set . <- NULL, but is there a more rigorous way to set this using rlang? Understanding the recommended guidelines here would allow our package to be developed to community standards.

Disclaimer: This is now cross-posted from here, since it hasn't received a reply in several days.

user4687531
  • 1,021
  • 15
  • 30
  • 1
    This page might be helpful: https://github.com/STAT545-UBC/Discussion/issues/451#issuecomment-264598618 – Will Oldham Mar 26 '21 at 13:04
  • Many thanks @WillOldham. I'd seen this link. If you scroll down, this comment: https://github.com/STAT545-UBC/Discussion/issues/451#issuecomment-385731301, suggests the fix for `dplyr` verbs using `rlang`. In the case I'm asking for it is to control the `.` specifically i.e. outside of `dplyr`. Would you have any ideas how to fix for this case? The GlobalVariables approach can have other implications, which I'm trying to safely avoid. – user4687531 Mar 26 '21 at 13:06
  • 5
    Use `utils::globalVariables(".")` to silence this. – Lionel Henry Mar 26 '21 at 13:20
  • 1
    Many thanks @LionelHenry (for this and your contributions to tidyeval). Just for further clarification, I have a few follow up questions. 1. Could this `utils::globalVariables(".")` approach have unintended global side-effects? 2. Is the only advantage of using `utils::globalVariables(".")` over `. <- NULL` locally is that it needs to be set once, or are there more issues with the `NULL` local approach. 3. I'm curious whether there are any `dplyr` `.data` style fixes for this specific issue, since the `.` is commonly passed around in `%>%` code? – user4687531 Mar 26 '21 at 14:14
  • 1
    For unintended effects, the flip side of declaring a global variable is that you won't get warnings when you use `.` in a place where it is not defined. In that case though, it is unlikely you would call a real variable `.` so there is no issue. Regarding `. <- NULL`, the `globalVariables()` declariation is more explicit. I'm not aware of an importable `.` but this were possible there would be no advantage to importing it over declaring it global. – Lionel Henry Mar 29 '21 at 06:25
  • Thanks @LionelHenry. This is really helpful. One last question. Should we then add it like this in our main package level doc: https://github.com/jennybc/googlesheets/blob/master/R/googlesheets.R#L15-L16? Is there any advantage to add the `if(getRversion() >= "2.15.1")` line? – user4687531 Mar 30 '21 at 02:09
  • The conditional makes it work on R < 2.15.1. This is a really old version. – Lionel Henry Mar 30 '21 at 07:50
  • I got a little confused by this. Doesn't the `globalVariables(".")` only get executed if the `R >= "2.15.1"`. Since there is no else expression, I thought this means that there is no such `globalVariables(".")` assignment for `R < 2.15.1` i.e. older versions of `R` are **not** covered by this global variable. I don't expect any of our package users to have such an old `R` version, but it seems to me like this constraint does not cover the older version. Sorry for being naive here, but could you clarify the issue in my thinking above? – user4687531 Mar 30 '21 at 21:50
  • @user4687531, if not the OP, tag the person for them to receive a notification. The if(getRversion() >= "2.15.1") prevents build failure on R versions <2.15.1, where globalVariables doesn't exist. Attempting to call it would result in an error. Not declaring . in these versions merely gives a minor warning during RCHECK, not during build/load - it's a negligible issue (probably either way). – jan-glx Jun 29 '23 at 16:20

1 Answers1

4

This alert comes from the codetools package. Apart from the other solution, there is also an option of not using codetools completely in R CMD check. In your ~/.Renviron file (to quickly open from R console, use usethis::edit_r_environ()), add a line as such:

_R_CHECK_USE_CODETOOLS_= FALSE

This is recommended if you do a lot of NSE which throws many false alerts.

Siqi Zhang
  • 51
  • 4
  • 2
    Turning this off would prevent valid warnings of undeclared variables though correct? As in, you wouldn't get a warning that you reference a global variable – gabagool Jan 28 '23 at 21:26