basiliskOptions: Options for 'basilisk'
In basilisk: Freezing Python Dependencies Inside Bioconductor Packages

Description Usage Arguments Details Value Author(s) See Also Examples

Options controlling the efficiency and friendliness of starting up a Python instance via basilisk.

getBasiliskFork()

setBasiliskFork(value)

getBasiliskShared()

setBasiliskShared(value)

value

Logical scalar:

For setBasiliskFork, whether forking should be used when available.
For setBasiliskShared, whether the shared Python instance can be set in the R session.

By default, basiliskStart will attempt to load a shared Python instance into the R session. This avoids the overhead of setting up a new process but will potentially break any reticulate-dependent code outside of basilisk. To guarantee that non-basilisk code can continue to execute, users can set setBasiliskShared(FALSE). This will load the Python instance into a self-contained basilisk process.

If a new process must be generated by basiliskStart, forking is used by default. This is generally more efficient than socket communication when it is available (i.e., not on Windows), but can be less efficient if any garbage collection occurs inside the new process. In such cases, users or developers may wish to turn off forking with setBasiliskFork(FALSE), e.g., in functions where many R-based memory allocations are performed inside basiliskRun.

If many basilisk-dependent packages are to be used together on Unix systems, setting setBasiliskShared(FALSE) may be beneficial. This allows each package to fork to create a new process as no Python has been loaded in the parent R process (see ?basiliskStart). In contrast, if any package loads Python sharedly, the others are forced to use parallel socket processes. This results in a tragedy of the commons where the efficiency of all other packages is reduced.

All functions return a logical scalar indicating whether the specified option is enabled.

Aaron Lun

basiliskStart, where these options are used.