What Happened
Rig 0.11.0 expands rig pkg, the R package-management commands introduced across versions 0.10.0 and 0.11.0. They can install, remove, list, check, inspect and search packages. Installation accepts CRAN-like repositories, git and GitHub sources, URLs, local files and version constraints. Rig caches files, skips redundant work, parallelizes downloads and builds, and rejects incompatible dependency requests [1].
New diagnostic commands include rig pkg doctor for library checks and suggested fixes, and info, deps and tree for package and dependency inspection. Project-specific libraries remain the job of rig proj; named libraries can be managed with rig library [1].
This release is an R environment-management update, not a reported release of Streamlit, Quarto, Jupyter, Shiny, Gradio, Chainlit, Modal or Replicate. Those tools may sit elsewhere in an application stack, but the change here is how R dependencies are installed and maintained [1].
Why It Matters to Businesses
Dependency failures can delay deployments and make a data app behave differently across developer machines, CI and production. Rig’s dependency checks, library inspection and cached, parallel installation give teams more ways to detect problems early and reduce repeated setup work. Version listings depend on P3M metadata, so they should not be assumed to work for every repository [1].
Kimbodo Engineering Perspective
We would treat rig as environment tooling, not an application framework. Shiny or a notebook workflow still needs its own decisions about user access, hosting, monitoring and data handling. Rig is most useful when teams define which R version, repositories and libraries a project should use, rather than relying on its defaults—which can otherwise vary between environments [1].
How We Would Implement It
- Define the R version, approved repositories and project library explicitly in development and CI; use rig proj for project-specific dependencies [1].
- Run dependency installation during image builds or CI, then run rig pkg doctor and inspect the dependency tree before deployment [1].
- Build and test the data app against that environment, promoting the tested artifact to production rather than reinstalling packages at application startup.
Risks, Costs and Security
Rig can install Linux system requirements with root access or password-less sudo; in user mode, it uses self-contained manylinux builds. We would prefer the least-privileged build path that meets the application’s needs and review any request for elevated installation privileges. Because rig also accepts git, URLs and local files, production builds should restrict package sources and review changes to dependency versions. Caching and parallel work can reduce build effort, but neither substitutes for testing the resulting application [1].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Application Development practice, or Estimate My AI Application.
