Closed Darxor closed 1 year ago
Hmm I like the idea in general, but it would add 3 dependencies to tidytable
- conflicted
, memoise
, and cachem
. I would like to avoid that.
I could just recommend that users use conflicted
. I also have debated recommending users to use box
.
Another option is to export an import_as()
function that mimics the functionality of box
using python-like syntax. In the example below dplyr
functions are accessed using dp$
pacman::p_load(rlang, tidytable)
import_as <- function(package, alias) {
package <- as_name(enexpr(package))
funs <- set_names(getNamespaceExports(package))
funs <- map(funs, ~ eval(call2("::", sym(package), sym(.x))))
funs <- as_environment(funs)
env_bind(caller_env(), {{ alias }} := funs)
}
library(dbplyr)
import_as(dplyr, dp)
df <- memdb_frame(x = 1:3, y = 1:3, z = c("a", "a", "b"))
df %>%
dp$select(x, y, z) %>%
dp$mutate(double_x = x * 2) %>%
dp$collect() %>%
summarize(mean_x = mean(x), .by = z)
#> # A tidytable: 2 × 2
#> z mean_x
#> <chr> <dbl>
#> 1 a 1.5
#> 2 b 3
import_as()
seems to me as good option for an advanced user, but maybe less so for an average one.
I would personally wrap tidytable_prefer()
with a check for installed {conflicted}
and push conflicted
into Suggests, rather then Imports. If {conflicted}
is not installed - throw a message with info about load order and suggest using import_as()
or {box}
directly.
As I think on this, I think this is sufficiently covered by the conflicted
package.
conflicted::conflict_prefer_all("tidytable", quiet = TRUE)
With dotless verbs now in place, I thinks its would be a good idea to implement something along the lines of
tidymodels::tidymodels_prefer()
and add a readme about it.IMO, this will make it easier for an average user in an interactive session, where one doesn't necessarily knows which package will they load first.
{conflicted}
(what tidymodels devs use) seems like a rather lightweight solution for this