1. Writing new scripts
Choose a date, a good default is the first day of the month when starting your project, and load all packages for that date.
For example
library(groundhog)
pkgs <- c(pkg1, pkg2, pkg3, pkg4)
groundhog.library(pkgs, '2021-09-01')
<your code>
Then, when you run or edit that script in the future, you can either stick with the date you chose originally, or you can make the script up-to-date by just changing that one value.
If you will use multiple groundhog.libray() calls, you can set the date as a variable.
groundhog.day <-'2021-09-01'
groundhog.library(pkgs, groundhog.day)
2. Make existing scripts reproducible.
You can take any script that already exists, and retrofit it to make it reproducible in the future.
Set groundhog.day
as if writing a new script. If the script runs as expected, with groundhog.day
you chose , now you know it will continue running in the future. If it does not run as expected, try an earlier grounghog.day
, perhaps the date from when the script was created or last saved. Once you find a date for which it works, the script will continue working.
3. Running/editing existing scripts.
When running a script that already relies on groundhog
, using the existing groundhog.day
value may make things slow (e.g., you may need to switch to an older version of R or install older packages from source). It may make sense to comment out the #groundhog.day in the script, and set groundhog.day
to a more recent date. This approach to using groundhog
is similar to how people are supposed to use R, keeping packages up to date over time, except that:
- The package updating is accomplished by changing a single line of code: resetting
groundhog.day
. - You know all packages in a script are simultaneously updated, and only if they need to be.
- Package updates are easy to reverse, and can be stopped, at any point.
- Future users of a script will load the same package versions used when the script was saved.
- Updates for one script will not affect other scripts that rely on the same packages