19

I am trying to use where in my own R package. I was going to use it in the code as tidyselect::where() but the function is not exported. For this same reason, you cannot use @importFrom tidyselect where.

I do not want to reference it with :::. The code will work if I simply refer to it as where(), but then I receive a note in the checks.

Undefined global functions or variables: where

What is going on here? I assume the function works as is since it it captured as an expression in my code, and tidyeval knows how to handle it on evaluation?

Example

As an example, if you start a clean R session, the following will work (dplyr 1.0.0) without running library(dplyr). It clearly knows how to handle where.

dplyr::mutate(iris, dplyr::across(where(is.numeric), ~.x + 10))

Likewise, this will also work, but I do not want to use it in a package. So I use the above, which gets flagged in devtools::check().

dplyr::mutate(iris, dplyr::across(tidyselect:::where(is.numeric), ~.x + 10))

Question

How do I use where from tidyselect in a package without it being flagged as undefined?

  • 1
    Does this answer your question? [Using un-exported function from another R package?](https://stackoverflow.com/questions/32535773/using-un-exported-function-from-another-r-package) The top answer there explains how to use unexported functions from other packages in a way that CRAN allows (which should get rid of your R CMD check flag) – duckmayr Jun 18 '20 at 21:54
  • 1
    Yes and no. Yes in that it does appear to be a solution. No in that it seems a bit tedious for the tidyverse. Given how they are all about making things easier, having to do something like that for what should be commonly used function going forward seems a bit odd. So my assumption now is that they either (a) have a smoother recommended way (i.e., I am doing something wrong) or (b) perhaps intended to export and it may be helpful to bring it up as an issue. I thought I would ask here because somebody usually knows. –  Jun 18 '20 at 22:14
  • 2
    See [this GitHub issue](https://github.com/r-lib/tidyselect/issues/201) where this is discussed. They have purposefully not exported it, for now, because `where()` is such a general name that they were reluctant to do so initially, but admit they will likely do so eventually. They allude to a workaround for the R CMD check issue, but to me it seems likely to refer to the same workaround as I linked to – duckmayr Jun 18 '20 at 22:44
  • 1
    @duckmayr since you posted there has been more discussion on the issue, and `utils::globalVariables("where")` is what they recommend. –  Oct 09 '20 at 18:01
  • 1
    Good news - since tidyselect 1.2.0 `where()` is exported https://github.com/r-lib/tidyselect/releases/tag/v1.2.0 – nstjhp Nov 15 '22 at 14:39

1 Answers1

33

There is an existing workaround for this type of problem. One of the items that is exported from tidyselect is a list of helper function called vars_select_helpers. This includes where, so if you do

mutate(iris, dplyr::across(tidyselect::vars_select_helpers$where(is.numeric), ~.x + 10))

You should get the same functionality without any grumbling from the check tools.

Allan Cameron
  • 147,086
  • 7
  • 49
  • 87