R Users Can Now Access Any Python Package Without Knowing Python

The Idea

The goal was simple. R users should be able to download Dewey data with a single function call and zero Python setup. No conda environments, no pip installs, no terminal commands they don’t understand.

The solution was system2 and uv.

system2 is a base R function that lets you run shell commands from inside an R script. Most R users have never touched it. Combined with uv, a Python package and environment manager that is extremely fast and lightweight, you can spin up a fully isolated Python environment, install any Python package, run it, and capture the output back in R. The user never sees any of it.

The Terminal is Just a Function Call

Before getting into system2 it helps to understand what is actually happening when you run something in the terminal.

When you run a Python script from the terminal it looks like this:

python file.py arg1 arg2 arg3

That is it. You have a program (python), a file to run (file.py), and any arguments the script expects. Most command line tools follow this same pattern. The program name comes first, then everything else is arguments passed to it.

Say you had a simple Python script called greet.py:

import sys

name = sys.argv[1]
language = sys.argv[2]

if language == "english":
    print(f"Hello, {name}!")
elif language == "spanish":
    print(f"Hola, {name}!")

You would run it from the terminal like this:

python greet.py Mitchell english
# Hello, Mitchell!

system2 just maps directly onto this. The first argument is the program, and args is everything that comes after it as a character vector:

system2(
  "python",
  args = c("greet.py", "Mitchell", "english"),
  stdout = TRUE
)
# "Hello, Mitchell!"

You can wrap this in a clean R function so the user never thinks about the terminal:

greet <- function(name, language = "english") {
  system2(
    "python",
    args = c("greet.py", name, language),
    stdout = TRUE
  )
}

greet("Mitchell")
# "Hello, Mitchell!"

That is the core idea. Anything you can run from a terminal you can run from R with system2. The R user just calls a function.

From Scripts to Packages

Most useful tools are not standalone files though. They are distributed as packages you install and run as a module. In the terminal that looks like this:

python -m deweypy --api-key mykey --download-directory ./data speedy-download folder123

The -m flag tells Python to run a package as a module instead of a file. Everything after it is just arguments the package expects. system2 maps onto this exactly the same way:

system2(
  "python",
  args = c(
    "-m", "deweypy",
    "--api-key", "mykey",
    "--download-directory", "./data",
    "speedy-download", "folder123"
  ),
  stdout = TRUE,
  stderr = TRUE
)

Because each argument is its own element in the character vector, adding optional arguments conditionally is clean and readable. Here is the actual core of how deweyr builds its command:

run_deweypy <- function(python_path,
                        api_key,
                        download_path,
                        folder_id,
                        num_workers = NULL,
                        partition_key_before = NULL,
                        partition_key_after = NULL) {

  # Build base arguments
  args <- c(
    "-m", "deweypy",
    "--api-key", api_key,
    "--download-directory", download_path,
    "speedy-download", folder_id
  )

  # Add optional arguments only if provided
  if (!is.null(num_workers)) {
    args <- c(args, "--num-workers", as.character(num_workers))
  }

  if (!is.null(partition_key_before)) {
    args <- c(args, "--partition-key-before", partition_key_before)
  }

  if (!is.null(partition_key_after)) {
    args <- c(args, "--partition-key-after", partition_key_after)
  }

  system2(python_path, args = args, stdout = TRUE, stderr = TRUE)
}

You start with the arguments every call needs, then build up from there. Optional parameters only get added if the user passed them in. The command that actually runs in the terminal is whatever args looks like at the end. This is cleaner than hardcoding a Python one-liner as a string and makes it easy to add new arguments later without touching the system2 call itself.

Wrap this in a user-facing function that handles the uv setup, path creation, and URL parsing first, and the R user just calls dewey_download() with their API key and folder ID. Everything else is invisible to them.

Understanding system2

system2 is a base R function that calls a system command the same way you would from a terminal. The basic signature looks like this:

system2(
  command,   # the program to run
  args,      # a character vector of arguments
  stdout,    # where to send standard output
  stderr,    # where to send standard error
  input      # optional: feed text into stdin
)

The thing that trips people up at first is that by default stdout and stderr are both "", which means the output goes to the console and is not captured in R. If you want to actually work with the output you need to set stdout = TRUE, which returns it as a character vector. Each line of output becomes one element of the vector.

# This prints to console but returns nothing useful
system2("uv", args = c("--version"))

# This captures the output so you can use it in R
version <- system2("uv", args = c("--version"), stdout = TRUE)
# version is now something like "uv 0.5.1"

stderr works the same way. By default errors go to the console. Set stderr = TRUE to capture them, or stderr = FALSE to suppress them entirely. If you want both stdout and stderr together in one vector you can set stderr = TRUE alongside stdout = TRUE and they will be interleaved.

The return value when you are not capturing output is the exit code of the process. 0 means it ran fine, anything else means something went wrong. This is useful for checking if a command succeeded before moving on:

exit_code <- system2("uv", args = c("--version"), stdout = FALSE, stderr = FALSE)
if (exit_code != 0) stop("uv is not installed or not on PATH")

One other useful argument is input, which lets you pipe a string into the command’s stdin. This is how you can chain commands together without writing intermediate files.

The main thing to keep in mind is that system2 is blocking. R waits for the command to finish before moving on. For long downloads that is fine. For something you want to run in the background you would need a different approach.

How It Works

When someone calls dewey_download() for the first time, here is what actually happens under the hood:

1. R checks if uv is installed. If not, it installs it automatically.
2. uv downloads a lightweight Python 3.13 installation. No system Python needed.
3. uv creates an isolated virtual environment and installs deweypy into it.
4. system2 runs the Python downloader with the user’s arguments.
5. The files land in whatever folder the user specified.

From the R user’s perspective, they just called a function.

library(deweyr)

dewey_download(
  api_key = "your-api-key",
  folder_id = "your-folder-id"
)

That is it. No Python. No terminal. No environment to manage.

Signed URLs and DuckDB

One thing deweypy does that makes this even more useful is generate signed URLs for the files. Instead of downloading everything locally, you can pull the URLs back into R and read them directly with DuckDB. This is useful for large datasets where you only need a slice.

get_signed_urls <- function(api_key, folder_id) {
  result <- system2(
    "uv",
    args = c(
      "run", "--with", "deweypy",
      "python", "-c",
      paste0(
        "import json; from dewey import Dewey; ",
        "d = Dewey('", api_key, "'); ",
        "urls = d.get_file_urls('", folder_id, "'); ",
        "print(json.dumps(urls))"
      )
    ),
    stdout = TRUE
  )

  jsonlite::fromJSON(paste(result, collapse = ""))
}

Then in R you can pass those URLs straight to DuckDB:

library(duckdb)
library(DBI)

urls <- get_signed_urls(api_key = "your-key", folder_id = "your-folder")

con <- dbConnect(duckdb())
df <- dbGetQuery(con, paste0("SELECT * FROM read_parquet('", urls[1], "') LIMIT 1000"))

No full download needed. Just query what you need.

The Bigger Point

deweypy is just the example. This pattern works for any Python package that does not have an R equivalent. The only thing an R user needs to install is uv. Everything else is handled by the package. That is a low enough bar that you can actually ship it to non-technical users and expect it to work.

If you are building R packages and running into Python tools that do something yours cannot, system2 plus uv is worth knowing.

The full package is on GitHub at Coxabc/deweyr if you want to see how it is all wired together.

What You Need Before Starting

Before touching PyPI, the package should be installable from GitHub and have a working pyproject.toml. The canvasconnector README already had installation instructions pointing at the GitHub repo:

uv pip install git+https://github.com/byuirpytooling/canvasconnector.git

That is fine for early development, but it is not discoverable and it requires users to know the exact GitHub URL. PyPI solves both of those problems.

You also need a PyPI account. Head to pypi.org, sign up, and verify your email before continuing. If it gives you recovery codes, save them somewhere safe or risk losing access.

The First Upload: Manual with Twine

PyPI requires the package to exist before you can configure automated publishing. So the first upload is manual. Start by building the package with uv:

uv build

This creates a dist/ folder containing two files: a .whl wheel file and a .tar.gz source distribution. Then install twine as a global tool:

uv tool install twine

twine upload dist/*

Setting Up OIDC Trusted Publishing

OIDC (OpenID Connect) lets PyPI verify that a publish request is coming from a specific GitHub Actions workflow in a specific repository, without any stored credentials. No token to manage, rotate, or accidentally leak.

name: Upload Python Package

on:
  release:
    types: [published]

permissions:
  contents: read

jobs:
  release-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.x"

      - name: Build release distributions
        run: |
          pip install uv
          uv build

      - name: Upload distributions
        uses: actions/upload-artifact@v4
        with:
          name: release-dists
          path: dist/

  pypi-publish:
    runs-on: ubuntu-latest
    needs: release-build
    environment:
      name: pypi
    permissions:
      id-token: write
    steps:
      - name: Retrieve release distributions
        uses: actions/download-artifact@v4
        with:
          name: release-dists
          path: dist/

      - name: Publish release distributions to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          packages-dir: dist/

Publishing a New Release

With everything wired up, releasing a new version is a deliberate three-step process:

1. Bump the version in pyproject.toml (for example, 0.0.1 to 0.0.2)
2. Commit and push the change
3. Go to your GitHub repo and find the Releases section in the right sidebar, then click Create a new release

Create a tag matching the version (like v0.0.2), write release notes, and click Publish release. The workflow fires automatically from there.

The reason releases are manual rather than triggered on every push is intentional. A PyPI publish is permanent. You cannot overwrite or delete a version once it is live. Keeping the release step manual means you are making a conscious decision each time rather than accidentally shipping a half-finished commit.

Verifying the Install

After publishing, the fastest way to confirm everything works is to create a fresh project and install from PyPI:

mkdir canvasconnector-test
cd canvasconnector-test
uv init
uv add canvasconnector

Then run a quick import to confirm it loads correctly. For canvasconnector, a successful connection looks like this:

https://byui.instructure.com
America/Denver
Connected successfully as: Mitchell Mecham

If that works, the package is live, installable, and functioning correctly for any user who finds it.

Summary

The full process from GitHub-only to automated PyPI releases:

1. Build with uv build and upload manually with twine upload dist/* using an API token
2. Create a PyPI account and generate a temporary API token under account settings scoped to all projects
3. Once the package exists on PyPI, go to Manage > Publishing on the project page to configure OIDC trusted publishing
4. Create a pypi environment in GitHub repository settings
5. Add the publishpypi.yml workflow with id-token: write permissions and no stored credentials
6. For each future release: bump the version, push, and create a GitHub Release to trigger the workflow

The canvasconnector package is available at pypi.org/project/canvasconnector and the full source is at github.com/byuirpytooling/canvasconnector.

The Stack

Frontend — React The UI is built in React, giving users a fast, responsive experience. It handles authentication input (your Canvas API token) and displays your courses and friends in a clean dashboard.

Backend — FastAPI FastAPI serves as the bridge between the React frontend and Canvas. It exposes endpoints the frontend calls to fetch user data, and handles all the Canvas API communication server-side.

The Secret Sauce — canvasconnector The backend is powered by canvasconnector, a Python library that wraps the Canvas REST API into clean, Pythonic calls — so FastAPI doesn’t have to deal with raw HTTP requests to Canvas directly.

What It Does

• 🎓 Shows you your enrolled courses
• 👥 Displays your Canvas friends and classmates
• 🔑 Uses your personal Canvas API token to authenticate

What’s Next?

An interactive version of this post using marimo is on the roadmap — imagine entering your Canvas API token right here on the page and seeing your courses load instantly. Stay tuned.