Background
Follow-up to #614, which fixed CI
The short version of what went wrong: renv.lock pointed at the Posit Package Manager "latest" address, which only ever offers the newest version of each package. Over time 154 of our 374 pinned versions aged out of it. When renv can't get a ready-built package it falls back to compiling from source, and many of those older versions won't build on a current Linux machine.
Nothing broke for months because GitHub was caching the whole package library between runs, so nothing was actually being installed. When GitHub moved our builds to a newer Ubuntu image in mid-July the cache was discarded (it's keyed on the OS version) and every run suddenly had to install all 374 packages for real. That's when it fell over, on every branch at once, including pushes straight to main.
The PR fixed the immediate problem by pinning a dated snapshot, but that date now needs moving forward periodically or the same drift accumulates again.
Proposal
Add utils/renv_check_lockfile.R, a read-only audit that answers the question would a cold renv::restore() succeed right now?
By checking that the repository URL is a dated snapshot, that every recorded version still exists at that date on Linux, macOS and Windows, that no base/recommended packages are pinned, that every package's Repository name is declared, and that the snapshot date isn't stale; it should exit non-zero and run monthly plus on any PR touching renv.lock.
A follow-up could add utils/renv_bump_snapshot.R to perform the update in CI, which must install and then renv::snapshot() rather than editing the lockfile by hand, and must stash requirements.txt and the Python block across the snapshot to avoid the local environment leak that affected #608.
Background
Follow-up to #614, which fixed CI
The short version of what went wrong:
renv.lockpointed at the Posit Package Manager "latest" address, which only ever offers the newest version of each package. Over time 154 of our 374 pinned versions aged out of it. When renv can't get a ready-built package it falls back to compiling from source, and many of those older versions won't build on a current Linux machine.Nothing broke for months because GitHub was caching the whole package library between runs, so nothing was actually being installed. When GitHub moved our builds to a newer Ubuntu image in mid-July the cache was discarded (it's keyed on the OS version) and every run suddenly had to install all 374 packages for real. That's when it fell over, on every branch at once, including pushes straight to
main.The PR fixed the immediate problem by pinning a dated snapshot, but that date now needs moving forward periodically or the same drift accumulates again.
Proposal
Add
utils/renv_check_lockfile.R, a read-only audit that answers the question would a coldrenv::restore()succeed right now?By checking that the repository URL is a dated snapshot, that every recorded version still exists at that date on Linux, macOS and Windows, that no base/recommended packages are pinned, that every package's
Repositoryname is declared, and that the snapshot date isn't stale; it should exit non-zero and run monthly plus on any PR touchingrenv.lock.A follow-up could add
utils/renv_bump_snapshot.Rto perform the update in CI, which must install and thenrenv::snapshot()rather than editing the lockfile by hand, and must stashrequirements.txtand thePythonblock across the snapshot to avoid the local environment leak that affected #608.