Python r interoperability

Python-R interoperability

Summary

Enable a Shiny R application to call Python dependencies and manage their lifecycle through environment configuration and virtual environment setup. This skill allows R-based omics analysis workflows to leverage Python packages (e.g., Kaleido for static image rendering) without requiring users to manage Python separately.

When to use

When a Shiny R application needs to use Python libraries that lack R equivalents or are more mature in Python (e.g., Kaleido for plot export), and users should not need to manually configure Python environments. Specifically use this skill when replacing R-native plotting backends (orca) with superior Python alternatives that improve export robustness or performance.

When NOT to use

• When equivalent, well-maintained R packages exist for the required functionality (e.g., use R's native plotting libraries instead of Python for simple plots).
• When deployment environment cannot support Python virtual environments or when user system policies prohibit dual language runtimes.
• When the Python dependency requires system libraries not available in the target Docker or deployment container.

Inputs

• R Shiny application source code
• Python requirements.txt file listing dependencies (e.g., kaleido==5.x.x)
• YAML configuration file mapping python_venv path
• Omics visualization objects (e.g., ggplot2 or plotly objects to be exported)

Outputs

• Configured Shiny application with Python backend connectivity
• Python virtual environment linked to R runtime
• Static export files in multiple formats (PNG, JPEG, SVG) rendered via Python backend
• Environment variable MAP_CONFIG set and validated

How to apply

Create a Python virtual environment with required packages listed in requirements.txt. Configure the Shiny application to discover this environment via a YAML configuration file (e.g., minio_config.yml or .yml with python_venv: <path>) and set the MAP_CONFIG environment variable to point to it. In R code, use the reticulate package or equivalent Python-calling mechanism to invoke Python functions from the virtual environment. Document the Python dependency list in a requirements.txt file that mirrors the R package dependencies tracked in renv.lock, ensuring both dependency systems remain in sync. Test that Python function calls execute successfully within the Shiny reactive context and that exported outputs (e.g., PNG/JPEG/SVG files from Kaleido) match expected quality and format specifications.

Related tools

• reticulate (R package enabling Python function calls and environment management from R/Shiny context)
• Kaleido (Python library for static image export of plots (replaces orca backend for PNG/JPEG/SVG rendering with configurable width, height, scale))
• renv (R dependency management system tracking R package versions in renv.lock; used in parallel with Python requirements.txt) — https://rstudio.github.io/renv/articles/renv.html
• Docker (Container platform enabling reproducible setup of both R and Python environments; Dockerfile-base installs system libraries and Python dependencies) — https://github.com/pmartR/PMart_ShinyApp
• Shiny (R web framework hosting the interactive omics application that calls Python functions for plot export) — https://github.com/pmartR/PMart_ShinyApp

Examples

Sys.setenv('MAP_CONFIG' = '/path/to/config.yml'); renv::restore(); shiny::runApp()

Evaluation signals

• MAP_CONFIG environment variable is set and points to a valid YAML file containing python_venv: <path> entry.
• Python virtual environment at the specified path contains all packages from requirements.txt (verified via pip list or venv introspection).
• Shiny application starts without Python import errors and reactive functions invoking Python code execute without exception.
• Plot export functions generate PNG, JPEG, and SVG files with correct dimensions matching configured width and height parameters; visual inspection confirms plots render correctly and are not corrupted.
• Docker build completes successfully with Kaleido installed as a Python dependency and orca references removed from Dockerfile-base.

Limitations

• Virtual environment path must be absolute; relative paths may fail across different user systems or container contexts.
• Python version compatibility must be maintained between requirements.txt and the R reticulate package's Python expectations; mismatches can cause runtime crashes.
• Docker image build complexity increases; base container must install Python and system libraries (e.g., libpython-dev) before Kaleido can be installed, extending build time and image size.
• Users running the app locally must manually create and activate a Python virtual environment; this adds a setup step beyond standard R package installation via renv::restore().
• Export performance depends on Kaleido's rendering speed; very large or complex plots may incur longer export times compared to lightweight bitmap backends.

Evidence

• [readme] You will also need a Python virtual environment with the packages from requirements.txt installed. Then, add a .yml file with python_venv: <path-to-your-venv> in it. Finally, set the MAP_CONFIG environment variable to point to that yml file.: "You will also need a Python virtual environment with the packages from requirements.txt installed. Then, add a .yml file with python_venv: <path-to-your-venv> in it. Finally, set the MAP_CONFIG"
• [discussion] Remove orca in favor of Kaleido: "Remove orca in favor of Kaleido"
• [other] Modify the Shiny application R code to configure Kaleido (instead of orca) as the plotting backend with width, height, and scale parameters for export functions.: "Modify the Shiny application R code to configure Kaleido (instead of orca) as the plotting backend with width, height, and scale parameters for export functions."
• [readme] Some in-development packages are not being tracked in renv.lock (to reduce Docker image build times). These can be seen in the install commonly updated packages section of Dockerfile-base.: "Some in-development packages are not being tracked in renv.lock (to reduce Docker image build times). These can be seen in the install commonly updated packages section of Dockerfile-base."
• [readme] We use renv to manage the details about dependencies, but try keep track of them manually in DESCRIPTION as well.: "We use renv to manage the details about dependencies, but try keep track of them manually in DESCRIPTION as well."