Troubleshooting

Known Issues & Solutions

If your issue is not listed here, please email Uri about it, or create an issue on groundhog’s github page.

Issue #1. Installation fails and console shows message
'/usr/bin/tar: This does not look like a tar archive'

This issue was fixed with groundhog 1.5.0.

Issue #2. Slow installation from source... ...followed by failure

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.

 Issue #3. Conflict with a different version of the same package persists after restarting R session

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.  Since groundhog v1.3.2, this issue is addressed more aggressively and explicitly. Your best bet is to follow the solutions proposed by the package as you encounter this issue.

Extreme solution.
One way to eliminate the problem at the root, is to get rid of all user-installed packages in your non-groundhog library; if they are not available, they cannot be loaded automatically. The fastest and more easily reversible way to do this is to:

  1. Run .libPaths()
  2. Navigate to the first folder listed (that’s the one with all your installed packages) and rename it, adding “_disabled” to its name (e.g., “4.0_disabled”)
  3. Create an empty folder with the original name (e.g., “4.0”)

Now all your previously installed packages are in the _disabled folder and thus not accessible to R Studio to load without your consent.
To revert this, simply delete the new folder (e.g, “4.0”),  and rename the existing folder again, “4.0_disabled” -> “4.0”

You may also achieve this running this code (at your own risk)

#1) Disable all installed packages
lib.now <- .libPaths()[1]
file.rename (lib.now, paste0(lib.now,"_disabled"))
dir.create(lib.now)

#2) Re-enable all installed packages
lib.now <- .libPaths()[1]
if (file.exists(paste0(lib.now,"_disabled")))
{
unlink(lib.now,recursive = T, force=T)
file.rename (paste0(lib.now,"_disabled"), lib.now)
}