1. Writing new scripts

To write new R scripts that are reproducible all you have to do is set a variable with the date you want all packages to be current for (e.g., the date when you started the project), and then use that variable in every call of groundhog.library()

You can call that variable whatever you’d like, is a reasonable default name.

Like this:


<your code>

Then, when you run or edit that script in the future, you can either stick with the you chose originally, or you can make the script up-to-date by just changing that one value.


2. Make existing scripts reproducible.

You can take any script that already exists, and retrofit it to make it reproducible in the future.
Set as if writing a new script. If the script runs as expected, with you chose , now you know it will continue running in the future. I
f it does not run as expected, try an earlier, 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 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 in the script, and set 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:

  1. The package updating is accomplished by changing a single line of code: resetting
  2. You know all packages in a script are simultaneously updated, and only if they need to be.
  3. Package updates are easy to reverse, and can be stopped, at any point.
  4. Future users of a script will load the same package versions used when the script was saved.
  5. Updates for one script will not affect other scripts that rely on the same packages