One command to install the HVTI R package family, and one command to say whether you are current.
Documentation: https://ehrlinger.github.io/hvtiR/
# install.packages("pak")
# pak::pak("ehrlinger/hvtiR")
install.packages("hvtiR", repos = c('https://ehrlinger.r-universe.dev', 'https://cloud.r-project.org'))
Then install every member:
hvtiR::install()
install.packages("pak")
# pak::pak("ehrlinger/hvtiR")
install.packages("hvtiR", repos = c('https://ehrlinger.r-universe.dev', 'https://cloud.r-project.org'))
hvtiR::setup(
study = "EDIT: the Study Tracker title",
study_tracker_id = 0L, # EDIT: the Study Tracker ID
root = "EDIT: the study directory"
)
Run this once per study, before anything else, from an R session started
outside any project, passing root =. From inside the study's RStudio project
it stops before installing anything and names the command to run: it replaces
packages that session has loaded. It also stops the study using renv's
per-user cache, so the shared library holds real copies a teammate can read,
and reinstalls any package that was only a link into someone's home. It cleans
up template copies first and only then locks the packages, so the lockfile records what the study declares and not what the templates
happened to mention. For an existing (legacy) study pass adopt = TRUE, which
is what cleans up its template copies. A study that already has a renv.lock
keeps its locked versions unless the declared family needs newer ones, in which case
setup() moves them, lists each move and records them (upgrade = TRUE, the default; pass
upgrade = FALSE for a study in revision, whose versions must not move), and every package that lockfile recorded is declared
on first conversion, so none drop out. No personal GitHub token is needed: the packages are installed with
pak, which carries a shared token, and renv keeps the environment (lockfile,
restore, snapshot). It is safe to rerun.
Every study gets the family and a standard set of analysis packages, with no
separate install step: tidyverse, haven, gtsummary, flextable,
survival, survminer, randomForestSRC, varPro and pacman, plus
arrow for registered data. setup() declares them in the study's
DESCRIPTION, so the lockfile records them. Add anything else with
hvtiRutilities::study_need().
hvtiR::status() # what is installed, what is available
hvtiR::update() # install only what is missing or stale
When pak recorded an installed package's GitHub commit, status() also catches
new commits on main that keep the same package version. The five-column table
stays version-focused; commit provenance is used internally to decide whether
an equal-version install is current.
hvtiR::status() also checks hvtiR itself against GitHub. The installer
stays outside the member table, but the report names the available version and
pak::pak("ehrlinger/hvtiR") when it is behind. hvtiR::update() reuses the
same check; it cannot update its own loaded namespace.
hvtiR::update() will refuse to overwrite a member you have already
attached in the session, because a loaded package cannot be safely replaced.
Restart R and run it again before attaching anything.
install() resolves every member from GitHub main, so it gives you the
newest code rather than a fixed one. Two people running it a week apart can end
up on different commits under the same version number. When an analysis has to
be reproducible, pin the versions with renv:
renv::init() # once per project
hvtiR::install() # installs into the project library
renv::snapshot() # records every package, and each member's commit
renv.lock then names the exact commit behind each member, and
renv::restore()
rebuilds that library on another machine. This works because pak records the commit it installed from, which is the field renv reads.
A member installed from a local working copy rather than from GitHub carries no
such commit, so renv has none to record for it. hvtiR::doctor() reports
whether an renv project is active.
hvtiR::doctor()
reports your R version against the family's requirement (4.4.0 or newer),
your platform, whether pak is available, the package repositories R is
configured to use, whether an renv project is active, and the full member
table. It warns when a repository is a dated snapshot and names each
dependency version floor a member declares that the repositories cannot meet.
When a GitHub check fails, it also reports the repository-specific reason.
| Package | Repository |
|---|---|
| hvtiRutilities | ehrlinger/hvtiRutilities |
| hvtiRdatabuild | ehrlinger/hvtiRdatabuild |
| hvtiRtables | ehrlinger/hvtiRtables |
| hvtiRtemplates | ehrlinger/hvtiRtemplates |
| hvtiPlotR | ehrlinger/hvtiPlotR |
| hvtiRlifetables | ehrlinger/hvtiRlifetables |
| hvtiRbootstrap | ehrlinger/hvtiRbootstrap |
| hvtiRpropensity | ehrlinger/hvtiRpropensity |
| hvtiRimputation | ehrlinger/hvtiRimputation |
| ggBoostedTrees | ehrlinger/ggBoostedTrees |
| TemporalHazard | ehrlinger/TemporalHazard |
| ggRandomForests | ehrlinger/ggRandomForests |
Members install from GitHub main because that is where family releases land
first. CRAN is a downstream republication for members that are published
there.
A later update.packages() can replace a GitHub installation with an older
CRAN release. This matters especially for TemporalHazard:
hvtiRlifetables declares Imports: TemporalHazard (>= 1.2.0), and R enforces
that requirement at namespace load. If a CRAN downgrade no longer satisfies
it, hvtiRlifetables will not load. hvtiR::status() will show
TemporalHazard as stale, and hvtiR::update() repairs it.
hvtiEDAreports (Python, archived 2026-08-27) and the HVTI Recipes book are not
R packages and are not members.