Lab 3: Distributing Internal Packages

By the end of this lab, you will be able to:

  • Install R so Package Manager can build packages
  • Configure Package Manager to use a specific version of R to build packages
  • Create a Git source and a git-builder to build an internal package from a Git repository
  • Create a repository and subscribe the Git source to it
  • Confirm the internal package is available in the Package Manager web interface
NoteBefore You Begin

This lab puts into practice the concepts covered in Distributing Internal Packages. If you have not read it yet, review it first so the steps below make sense.

TipRequired Reading

Install R

Building R packages from Git requires a working R installation on the Package Manager server.

Use the instructions in the documentation to install the latest version of R version.

NoteWhat is the latest version of R?

The Posit Install R documents are usually up to date, but should be checked against the CRAN Release Notes to make sure you are providing end-users the latest version of R.

The first line in this script specifies which version of R to install.

Terminal
export R_VERSION=4.6.0
curl -O https://cdn.posit.co/r/ubuntu-2404/pkgs/r-${R_VERSION}_1_$(dpkg --print-architecture).deb
sudo apt-get update
sudo apt-get install ./r-${R_VERSION}_1_$(dpkg --print-architecture).deb

The installers that Posit provides for R put the files required in /opt and allow you to install multiple versions side-by-side. You can check that R is correctly installed by running:

/opt/R/4.6.0/bin/R --version

which should produce the following output:

R version 4.6.0 (2026-04-24) -- "Because it was There"
Copyright (C) 2026 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.

Configure the Version of R Used to Build Packages

Now that R is installed, you need to ensure that Package Manager uses it. To specify the version of R that Package Manager should use, edit the configuration file at /etc/rstudio-pm/rstudio-pm.gcfg and add the following, using the version of R available in /opt/R:

/etc/rstudio-pm/rstudio-pm.gcfg
[Server]
RVersion = /opt/R/4.x.y
Tip

You can use ls -l /opt/R to check the available versions of R in that directory.

Warning
  • Make sure to replace /opt/R/4.x.y with the actual path to the version of R you have installed.
  • Note that this setting takes the path of the R installation directory, not the path to the R executable itself (i.e., do not include the bin/R at the end of the path).

After editing the configuration file, restart Package Manager so the change takes effect:

Terminal
sudo systemctl restart rstudio-pm

Build and Serve a Package from Git

Follow the instructions in the documentation to configure a Git-backed repository and build packages from Git. You can use the example repository referenced below, or your own Git repository if you have one available. The steps to follow are:

  1. Create a source. Use --type=git for R packages or --type=git-python for Python packages, and give it a name with the --name flag. This source links the Git repository to Package Manager.

    Terminal
    sudo rspm create source --type=git --name=internal-src

  2. Create a git-builder for the source. Specify whether to watch for commits on a branch or for tags. The value of --source must match the --name used above, and --url is the Git repository that contains the package code. Full documentation for this command is in the Appendix of the Admin Guide.

    Terminal
    sudo rspm create git-builder --source=internal-src \
   --url=https://github.com/mvuorre/exampleRPackage \
   --build-trigger=tags

  3. Create the repository that users will install from.

    Terminal
    sudo rspm create repo --name=git --description='Stable releases of our internal packages'

  4. Subscribe the source to the repository so the built packages are served from it.

    Terminal
    sudo rspm subscribe --source=internal-src --repo=git

Once subscribed, Package Manager clones the repository and runs a job in the background to build the package. For R, the package is then installed by users with install.packages (not remotes); for Python, it is installed with uv or pip.

Review the Build Activity

Because the build runs in the background, it is useful to confirm what Package Manager did. You can inspect build activity from the command line (or from the Activity Log in the web interface).

First, list the active git-builders to confirm yours is being tracked:

Terminal
sudo rspm list git-builders

Then list the builds for your source to see each build’s status and its transaction ID:

Terminal
sudo rspm list git-builds --source=internal-src --name=exampleRPackage

The output reports a Status (for example, suceeded or failed) and a Transaction ID. Use that ID to read the full build log, which is where you confirm a successful build or diagnose a failure:

Terminal
sudo rspm logs --transaction-id=<transaction-id>
Tip

The same history is available in the web interface under the Activity Log, which records each build attempt along with the Git tag or commit that triggered it. See Building Git-backed Packages for details.

Verify Your Work

Navigate to the web interface and confirm that you have a git repository and that the exampleRPackage package (or the one you chose) is available in that repository.

Tip

The build runs in the background and may take a moment to complete. If the package does not appear immediately, wait briefly and refresh.

  • Package Manager builds internal packages directly from a Git repository and serves them from the same infrastructure as CRAN and PyPI, giving teams a single, governed source of truth instead of hand-distributed tarballs.
  • Building requires the matching language runtime. Specify the R or Python version explicitly (for example, RVersion in the configuration file) rather than relying on file system scanning, so there is no ambiguity about which interpreter performs the build.
  • A Git-backed workflow assembles four pieces: a source (the upstream), a git-builder (attaches a repository and defines its build trigger), a repository (what users install from), and a subscription (connects the source to the repository).
  • Builds can trigger on commits or tags; tags give you control over which states of the repository become published versions. R archives previous versions as new ones are built, while Python keeps all versions available.