Integrating Package Manager with Workbench and Connect

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

  • Explain why Workbench and Connect should be pointed at Package Manager
  • Describe what changes when R and Python clients use Package Manager instead of CRAN and PyPI
  • Identify where repository configuration lives for Workbench and for Connect
  • Recognize how to confirm that a product is using Package Manager

Introduction

Standing up Package Manager only delivers value once the products that consume packages, Workbench and Connect, are actually pointed at it. By default, R installs from CRAN and Python installs from PyPI. Redirecting both products to Package Manager is what gives your organization control over which packages enter the environment, along with the performance benefit of pre-compiled Linux binaries.

This lesson explains why and where this integration happens. The accompanying lab walks you through configuring Workbench and Connect for both R and Python, and verifying that package installations flow through your Package Manager instance.

NoteTimings for this chapter
  • Reading time: 10 minutes
  • Documentation reading time: 15 minutes
  • Hands-on exercise time: 20 minutes
TipRequired Reading

Why Point Workbench and Connect at Package Manager

When Workbench and Connect use Package Manager rather than going directly to CRAN and PyPI, you gain two things at once.

The first is control. Every package a user installs in a Workbench session, or that Connect installs when deploying content, comes from a repository you govern. That is where the blocklist rules, curated sources, and vulnerability scanning from earlier lessons take effect. If the products bypass Package Manager, none of those controls apply.

The second is performance. CRAN does not provide pre-built binaries for Linux, so installing R packages directly from CRAN on a Linux server compiles them from source, which can be slow. Package Manager serves pre-built Linux binaries, dramatically reducing install times in both Workbench sessions and Connect deployments.

Where Configuration Lives

The integration is configured separately for each product and each language, because each uses a different mechanism.

  • Workbench, R: repository configuration is set so that R sessions resolve packages from Package Manager. The binary URL depends on the operating system Workbench runs on, so the correct OS-specific URL must be used to get binaries rather than source.
  • Workbench, Python: the Python package index is set for sessions, pointing pip (and tools that respect the same index) at Package Manager’s PyPI repository.
  • Connect, R: Connect’s CRAN repository is overridden to use Package Manager. Both your CRAN repository and any internal repositories (such as the git repository built earlier) should be configured as sources.
  • Connect, Python: Connect uses uv by default for Python content, and uv reads /etc/uv/uv.toml to determine its package index, so the configuration change for Python happens there.

Confirming the Integration Works

After configuring each product, you can confirm the change by installing a package and observing where it came from. In Workbench, the install logs should show Package Manager’s URL rather than CRAN or PyPI. The same principle applies to Connect: deploy content and confirm the packages resolve through your Package Manager instance during the set up of the environment.

NoteGoing further

We do not cover it in this lab, but you can also configure Workbench so that Positron Pro and VS Code get their extensions from Package Manager. You will first need to create an extension repository (see Serving Open VSX Extensions), and then configure Workbench to point at that repository (see Configuring Workbench for VS Code Extensions). Note that Positron and VS Code do not support authenticated extensions galleries.