JMP goes away when running a Python program in JMP 18

Question

I have been attempting to familiarize myself with the new Python interface in JMP 18.  One of the questions I am exploring is: "Is it possible to write a Python program in the JMP environment that executes r modules.  The very simple program I am using is

# Import the necessary libraries
import numpy as np
from rpy2.robjects.packages import importr
import rpy2.robjects as ro

# Create a numpy array
data = np.array([1, 2, 3, 4, 5])

# Convert the numpy array to an R vector
r_vector = ro.FloatVector(data)

# Import the base package in R
base = importr('base')

# Calculate the mean of the vector in R
mean = base.mean(r_vector)

# Convert the mean back to a Python float
mean_py = np.array(mean)[0]

print(f"The mean of the data is {mean_py}")

I installed the rpy2 package using the JSL

Python Install Packages( "rpy2");

It installed without issue.  I also installed it in my native 3.8 version of Python and in the native version of Python 3.11

The Python code runs without error in Python 3.8 and in JMP's installed 3.11.

However, when executing the code in Python under JMP 18, as soon as line 3 is run, JMP immediately goes away.

from rpy2.robjects.packages import importr

Does anyone have any ideas as to why this is happening?

Paul_Nelson · Answer

I think it's likely part of the issues mentioned within the jupyterlab issue 4871.  Specifically, the mention in one of the responses.

By default rpy2 will look for the first R found in the PATH. What can happen is that the R in the PATH does not match the R shared library picked up when dynamically loading it.

JMP loads Python as a shared library, so any shared library loading path would need to be in locations that JMP expects.  The embedded Python in JMP loads the rpy2 module, an it's shared libraries would be in the corresponding site-packages/ directory.  Then rpy2 tries to load the R shared libraries into the process space.  If a library can't be found, or fails to load due to a conflict, you will get a process termination deep down in a place JMP can't catch.  This was the issue we had long ago trying to use a Conda install of Python on Windows.  Conda moved the default locations around and didn't set the rpath, so JMP couldn't find Dlls that Python itself depended on and would promptly exit on trying to run anything Python with an Anaconda based install.  Further, none of the loaded Dlls will release and be unloaded until JMP itself shuts down.

I don't recommend using rpy2.  My personal preference / suggestion is to use pyRserve.  The package pyRserve is a Python thin client that talks to a Rserve server over TCP/IP.  There is an example in $SAMPLE_SCRIPTS/Python/Rserve.py that has extensive comments on configuration and use.

This isolates processes much better, and you are not loading R into Python's address space which is then within JMP.    With Rserv, a crash or issue within R will then have no effect on JMP.  Additionally, your Rserv instance can be run anywhere.  Locally in Windows or on macOS, within WSL (Windows Subsystem for Linux) on Windows, on a remote machine (Linux, macOS, ... ).  A remote R server may require additional network administration support such as firewall's and allowing ports.  Running locally, that shouldn't be an issue.

This is one of the dangers of allowing DLLs to be loaded in JMP.  Whether it is from within Python modules or from our own JSL load Dll capabilities.  A crash or error in the loaded DLL can cause an unrecoverable and unhandled error in JMP.

jthi · Answer

I couldn't get that package installed by using

Python Install Packages( "rpy2");

or

import jmp

import jmputils
# update to latest version of pip and setuptools then install numpy & pandas
jmputils.jpip('install --upgrade', 'pip setuptools')
jmputils.jpip('install', 'rpy2')

and I had to go through command-line. After I got it installed I'm facing the same issue, JMP will just close when I import rpy2.robjects (import rpy2 seems to work).  Maybe this is related to something like here https://github.com/jupyterlab/jupyterlab/issues/4817 ?