and sure enough after tidyverse tried to load after conflicted, the latter complained about dplyr::filter() vs. tools::filter(), breaking the process for reasons unrelated to groundhogr.
This may have to go rather deeply into the kind of exceptions you may have to raise. The patch (and perfectly good) solution is to groundhog.library("conflicted", date="whenever") the last among all the packages. Document it and declare a feature of the groundhogr operation rather than a tight corner :).
For a more robust and consolidated workflow, you may consider providing options like conflicted.preferences=list(conflicted_prefer_all="dplyr"), but it would not solve everything (I have dplyr::filter() vs tools::filter(), and I have haven::labelled() vs. labelled::labelled() that imports it vs. sjlabelled::labelled() that imports it, and I have summarytools::view() vs. tibble::view(). And then tidylog overwrites a good half of dplyr and tidyr stuff.)
I have tried a mass update of a lot of stuff that involved
and sure enough after
tidyverse
tried to load afterconflicted
, the latter complained aboutdplyr::filter()
vs.tools::filter()
, breaking the process for reasons unrelated togroundhogr
.This may have to go rather deeply into the kind of exceptions you may have to raise. The patch (and perfectly good) solution is to
groundhog.library("conflicted", date="whenever")
the last among all the packages. Document it and declare a feature of thegroundhogr
operation rather than a tight corner :).For a more robust and consolidated workflow, you may consider providing options like
conflicted.preferences=list(conflicted_prefer_all="dplyr")
, but it would not solve everything (I havedplyr::filter()
vstools::filter()
, and I havehaven::labelled()
vs.labelled::labelled()
that imports it vs.sjlabelled::labelled()
that imports it, and I havesummarytools::view()
vs.tibble::view()
. And thentidylog
overwrites a good half ofdplyr
andtidyr
stuff.)