hvtiR

One command to install the HVTI R package family, and one command to say whether you are current.

Documentation: https://ehrlinger.github.io/hvtiR/

Installation

# install.packages("pak")
pak::pak("ehrlinger/hvtiR")

Then install every member:

hvtiR::install()

Set up a study

install.packages("pak")
pak::pak("ehrlinger/hvtiR")
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, quarto for rendering jobs and ggiraph for interactive figures. setup() declares them in the study's DESCRIPTION, so the lockfile records them. Add anything else with hvtiRutilities::study_need().

Keeping current

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.

Reproducible installs

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.

When something will not install

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.

Members

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.

Further reading

• Reference - every function, with examples.
• Getting started - the vignette, including what to do when a member will not install.
• Changelog - what changed in each release.
• Design records - the spec and implementation plan, kept because the reasoning behind the design is harder to recover than the code.