Description
The pacakge cache utilities at this point work, but with issues like zkamvar/test-with-renv#17 where user intervention is required to update things, it would be good to step back and consider how the users will be using the cache.
Regular usage: bring in new packages, keep the old
At the moment, the pattern for building lessons assumes that anything can change in the source of the lessons, so we need to be prepared to bring in new packages, even if they are not currently installed. This is done with the following steps:
- hydrate (search for new packages added into the lesson and download them to the library)
- restore (restore the packages recorded in the lockfile)
- implicit snapshot (record the new packages in the lockfile and purging any unused packages from the lockfile)
Explicit updating: update existing and bring in new packages
I believe I need to revamp this to be more consistent on CI vs Local install. The restore may not be absolutely necessary, because once I had pinned {stringi}, I was able to run update_cache() with no trouble (context: one of the dependencies, adegenet, recently dropped it's strict dependency for {sf} and those dependencies disappeared on the repo)
Continuous integration
- restore (to bring in the cached packages)
- hydrate (this step is needed because of update_cache() does not update if packages are present in library, but not in lockfile #185)
- snapshot + compare against old lockfile to show new packages
- update
- snapshot
Locally
- update (because the package cache should already exist?)
- snapshot