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
You can call that variable whatever you’d like,
groundhog.day is a reasonable default name.
Then, when you run or edit that script in the future, you can either stick with the
groundhog.day 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.
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
- 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