Overview

The son.of.basilisk package (provided in the inst/example directory of this package) is provided as an example of how one might write a client package that depends on basilisk. This is a fully operational example package that can be installed and run, so prospective developers should use it as a template for their own packages. We will assume that readers are familiar with general R package development practices and will limit our discussion to the basilisk-specific elements.

Setting up the package

StagedInstall: no should be set, to ensure that Python packages are installed with the correct hard-coded paths within the R package installation directory.

Imports: basilisk should be set along with appropriate directives in the NAMESPACE for all basilisk functions that are used.

Specifying Python environments

library(basilisk)
my_env <- BasiliskEnvironment(envname="my_env_name",
    pkgname="ClientPackage",
    packages=c("pandas==2.2.3", "scikit-learn==1.6.1")
)

second_env <- BasiliskEnvironment(envname="second_env_name",
    pkgname="ClientPackage",
    packages=c("scipy=1.15.1", "numpy==2.2.2") 
)

#!/bin/sh

${R_HOME}/bin/Rscript -e "basilisk::configureBasiliskEnv()"

#!/bin/sh

${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe -e "basilisk::configureBasiliskEnv()"

Using the environments

my_example_function <- function(ARG_VALUE_1, ARG_VALUE_2) { 
    proc <- basiliskStart(my_env)
    on.exit(basiliskStop(proc))

    some_useful_thing <- basiliskRun(proc, fun=function(arg1, arg2) {
        mod <- reticulate::import("scikit-learn")
        output <- mod$some_calculation(arg1, arg2)

        # The return value MUST be a pure R object, i.e., no reticulate
        # Python objects, no pointers to shared memory. 
        output 
    }, arg1=ARG_VALUE_1, arg2=ARG_VALUE_2)

    some_useful_thing
}

my_example_function <- function() { 
    proc <- basiliskStart(my_env)
    on.exit(basiliskStop(proc))

    basiliskRun(proc, fun=function(store) {
        store$something <- rand(1)
        invisible(NULL) 
    }, persist=TRUE)

    basiliskRun(proc, fun=function(store) {
        store$something
    }, persist=TRUE)
}

Troubleshooting known issues

In most cases, end users should not have to read this document. Properly configured basilisk clients should handle all aspects of Python environment creation and loading without requiring user intervention. That said, some system configurations are less cooperative than others: this section contains a list of known issues and possible fixes.

Windows has a limit of 260 characters for its file paths. This is occasionally exceeded due to deeply nested directories for some packages, causing installation to silently fail. If this constraint is causing problems, it may be possible to circumvent them by setting BASILISK_EXTERNAL_DIR to a shorter path.

Builds for 32-bit Windows are not supported due to a lack of demand relative to the difficulty of setting it up.

Older versions of Rstudio on MacOSX have some difficulties with the generation of separate processes (see here). As a workaround in such cases, users should set:

parallel:::setDefaultClusterOptions(setup_strategy = "sequential")

basilisk will automatically attempt to remove old Python environments for each client package. However, this removal may not be fast enough on systems with low disk usage quotas, resulting in incomplete or failed installations. In such cases, users can forcibly clear the external directory themselves to free up some space:

# Remove obsolete environments for specific package:
basilisk::clearExternalDir(package = "pkg_name", obsolete.only = TRUE)

# Remove all environments for a specific package:
basilisk::clearExternalDir(package = "pkg_name")

# Remove all basilisk-managed environments:
basilisk.utils::clearExternalDir()

Fine-tuning basilisk’s behavior

Administrators of an R installation can modify the behavior of basilisk by setting a few environment variables. All environment variables described here must be set at both installation time and run time to have any effect. If any value is changed, it is generally safest to reinstall basilisk and all of its clients.

Setting the BASILISK_EXTERNAL_DIR environment variable will change where the environments are created by basiliskStart() during lazy installation. This is usually unnecessary unless the default path contains spaces or the combination of the default location and environment’s directory structure exceeds the file path length limit on Windows.

Setting BASILISK_USE_SYSTEM_DIR to 1 will instruct basilisk to install a client package’s environments in the R system directory during R package installation. This is useful for enterprise-level deployments as the environments are (i) not duplicated in each user’s home directory and (ii) always available to any user with access to the R installation. However, it requires installation from source and thus is not set by default.

Setting the BASILISK_CUSTOM_PYTHON_X_Y_Z environment variable will cause all requests for Python version X.Y.Z to use the Python binary at the specified path. This allows users to force basilisk to use their own Python installation instead of installing one via reticulate. The same approach can be used with BASILISK_CUSTOM_PYTHON_X_Y and BASILISK_CUSTOM_PYTHON_X for Python versions X.Y or X. Different client packages may need different Python versions so multiple environment variables may need to be set for different X/Y/Z combinations.

Setting the BASILISK_NO_PYENV environment variable will prevent basilisk from installing any new Python instances via Pyenv. If a requested Python version has no matching BASILISK_CUSTOM_PYTHON_* path, basilisk will throw an error instead of attempting an installation. This allows administrators to prevent unexpected installation of new Python instances, e.g., when the requested version of Python is already available but the assotiated BASILISK_CUSTOM_PYTHON_* variable has not been set.

Setting BASILISK_NO_DESTROY to 1 will instruct basilisk to not destroy previous environments upon installation of a new version of basilisk. This destruction is done by default to avoid accumulating many large obsolete environments. However, it is not desirable if there are multiple R instances running different versions of basilisk from the same Bioconductor release, as installation by one R instance would delete the installed content for the other. (Multiple R instances running different Bioconductor releases are not affected.) This option has no effect if BASILISK_USE_SYSTEM_DIR is set.

Using basilisk directly for analyses

While basilisk is primarily intended for package developers, end users can also take advantage of its graceful handling of multiple Python environments in complex workflows. For example, we can easily instantiate a Python environment in our working directory with createLocalBasiliskEnv():

tmp <- createLocalBasiliskEnv(
    "basilisk-vignette-test",
    packages=c("scikit-learn=1.6.1", "numpy=2.2.2")
)

## Installing pyenv ...
## Done! pyenv has been installed to '/github/home/.local/share/r-reticulate/pyenv/bin/pyenv'.
## Using Python: /github/home/.pyenv/versions/3.12.10/bin/python3.12
## Creating virtual environment '/tmp/Rtmpfs9UNf/Rbuilda6f1576a55a/basilisk/vignettes/basilisk-vignette-test/1.22.0' ...

## Done!
## Installing packages: pip, wheel, setuptools

## Installing packages: 'scikit-learn==1.6.1', 'numpy==2.2.2'

## Virtual environment '/tmp/Rtmpfs9UNf/Rbuilda6f1576a55a/basilisk/vignettes/basilisk-vignette-test/1.22.0' successfully created.

We can then supply this environment’s path to basiliskRun() to execute Python-based calculations. To demonstrate, we’ll apply scikit-learn’s truncated PCA on a random matrix. Note that the restrictions mentioned above for fun are still applicable here.

x <- matrix(rnorm(1000), ncol=10)
basiliskRun(env=tmp, fun=function(mat) {
    module <- reticulate::import("sklearn.decomposition")
    runner <- module$TruncatedSVD()
    output <- runner$fit(mat) 
    output$singular_values_
}, mat = x, testload="scipy.optimize")

## [1] 12.02781 11.72442

basiliskRun() can also be used with Python environments constructed outside of basilisk. Of course, in this case, it is the user’s responsibility to ensure that the environment is correctly provisioned.

library(reticulate)

tmp2 <- file.path(getwd(), "basilisk-vignette-test2")
if (!file.exists(tmp2)) {
    py.cmd <- suppressMessages(install_python(defaultPythonVersion))
    virtualenv_install(
        envname=tmp2,
        python_version=py.cmd,
        packages="scipy==1.15.1"
    )
}

## Using Python: /github/home/.pyenv/versions/3.12.10/bin/python3.12
## Creating virtual environment '/tmp/Rtmpfs9UNf/Rbuilda6f1576a55a/basilisk/vignettes/basilisk-vignette-test2' ...

## Done!
## Installing packages: pip, wheel, setuptools

## Virtual environment '/tmp/Rtmpfs9UNf/Rbuilda6f1576a55a/basilisk/vignettes/basilisk-vignette-test2' successfully created.
## Using virtual environment '/tmp/Rtmpfs9UNf/Rbuilda6f1576a55a/basilisk/vignettes/basilisk-vignette-test2' ...

basiliskRun(env=tmp2, fun=function(mat) {
    module <- reticulate::import("scipy.stats")
    norm <- module$norm
    norm$cdf(c(-1, 0, 1))
}, mat = x, testload="scipy.optimize")

## [1] 0.1586553 0.5000000 0.8413447

Notice how we were able to call basiliskRun() successfully on two different environments within the same R session. This enables the construction of complex analysis workflows that span across R and multiple Python environments.