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.
dplyr
verbs usingrlang
. In the case I'm asking for it is to control the.
specifically i.e. outside ofdplyr
. 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. – Safranineutils::globalVariables(".")
to silence this. – Knockerutils::globalVariables(".")
approach have unintended global side-effects? 2. Is the only advantage of usingutils::globalVariables(".")
over. <- NULL
locally is that it needs to be set once, or are there more issues with theNULL
local approach. 3. I'm curious whether there are anydplyr
.data
style fixes for this specific issue, since the.
is commonly passed around in%>%
code? – Safranine.
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
, theglobalVariables()
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. – Knockerif(getRversion() >= "2.15.1")
line? – SafranineglobalVariables(".")
only get executed if theR >= "2.15.1"
. Since there is no else expression, I thought this means that there is no suchglobalVariables(".")
assignment forR < 2.15.1
i.e. older versions ofR
are not covered by this global variable. I don't expect any of our package users to have such an oldR
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