Lab 3: Distributing Internal Packages

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

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

Before 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.

Required Reading

Configure the Version of R Used to Build Packages

In the installation lab, you installed the latest version of R. Now 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:

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
```
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
```

Create the repository that users will install from.

Terminal

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

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 pip.

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.