no visible binding for global variable ‘.’
Asked Answered
S

1

17

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.

Safranine answered 26/3, 2021 at 12:7 Comment(9)
This page might be helpful: github.com/STAT545-UBC/Discussion/issues/…Labors
Many thanks @WillOldham. I'd seen this link. If you scroll down, this comment: github.com/STAT545-UBC/Discussion/issues/…, 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.Safranine
Use utils::globalVariables(".") to silence this.Knocker
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?Safranine
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.Knocker
Thanks @LionelHenry. This is really helpful. One last question. Should we then add it like this in our main package level doc: github.com/jennybc/googlesheets/blob/master/R/…? Is there any advantage to add the if(getRversion() >= "2.15.1") line?Safranine
The conditional makes it work on R < 2.15.1. This is a really old version.Knocker
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?Safranine
@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).Appanage
G
6

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.

Gama answered 11/8, 2022 at 18:44 Comment(1)
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 variableYerkovich

© 2022 - 2024 — McMap. All rights reserved.