Troubleshooting

By far the most likely problem using groundhog is actually unrelated to groundhog. It involves not having a piece of software that R needs to install packages from ‘source’ (when you install from source you will see lots of text being printed quickly on the R console).

• For Windows all you need is R Tools. You can read more about it in our R Tools tab, or directly from the official  R Tools page.
• For Mac, the software you need can be found here: https://mac.r-project.org/tools/
• For Linux there are a variety of separate packages that need to be installed, usually the error message you obtain when relying on groundhog.library(), or on install.packages(), to install,  will indicate which library it is that you need.

MAC example
If on Mac Big Sur OSX 11, you run
groundhog.library('lme4', '2020-12-01')

the installation of the package Matrix will fail. Among the copious output in your console you will find this line indicating that gfortran is missing.

    ld: library not found for -lgfortran

You just need to install it from here https://mac.r-project.org/tools/, then Matrix, and thus lme4, will successfully install.

groundhog.library() verifies, before loading requested packages, that other versions of those packages are not already loaded. If they are, the loading ends prematurely, and you are invited to restart your R session (CTRL-SHIFT-F10 in R Studio). If even after restarting the R session the conflict persists, it means that the package creating the conflict is being reloaded automatically.

We have identified two ways for this to occur. One involves R Studio automatically loading packages, without your consent, e.g., when working on a markdown file.  The second is  improperly documented packages. Solutions for both causes are shown below.

Cause 1) R Studio & markdown
If you open a markdown file in R Studio it automatically loads a series of packages, and it will load whichever version you have available in your library. If you then want to load a package that has as a dependency one of those already loaded packages, a conflict will arise that will survive restarting the R session.

For example, as of January 13th 2021, R Studio automatically (and without notifying you) loads the packages knitr and xfun when opening a markdown file. If you then use groundhog to load those packages, or a package that has them as dependencies, e.g., tidyverse you may get a version conflict which restarting the R session will not alleviate. This is a reproducibility issue that is hard-coded into how R Studio currently works.  One extreme solution is to work on your .rmd files without using R Studio. An easier solution with a tiny risk of reproducibility breaking down is to tell groundhog to ignore this specific conflict with the ‘ignore.deps‘ argument, like this:

groundhog.library('tidyverse','2021-01-01', ignore.deps=c("xfun","knitr"))

groundhog.library() will keep the versions of those two packages loaded, even if they mismatch the versions implied by the groundhog.day date, and will load the correct version of all other packages.

Cause 2) Other
The other path to generate this problem is a bit obscure and infrequent, so let’s just get to the solution. If trying to groundhog.library(<pkgA>,groundhog.day) leads to an error where a dependency, pkgB, is already loaded, with a different version, you may:

Solution 1 (this is better). Actively load the conflicting dependency in a prior groundhog.library() call.

groundhog.library(<pkgB>, groundhog.day)
groundhog.library(<pkgA>, groundhog.day)

Solution 2 (this is worse). Include the conflicting package in the ignore.deps argument.

groundhog.library(<pkgA>, groundhog.day, ignore.deps=<pkgB>)

groundhog_1.1.0  produces an error if the path where packages are saved includes some special characters.
The issue was resolved in groundhog_1.2.0.
You can update groundhog by running:
install.packages('groundhog')