JMP 14 Python abilities - working? I'm confusedI'm trying to use the new abilities in JMP 14 to run python and it's not working. Basically not finding my python install I think though in some circumstances it just crashes.
I saw another discussion saying there were issues with that in 14.1 and suggesting a workaround about setting environment variables and using Use Python Version("3.6") as an argument to Python Init() (both of which I tried unsuccessfully).
Then I saw in release notes of 14.2 more about this, including a different name for relevant enviroment variable...
https://www.jmp.com/support/help/14-2/how-jmp-finds-python-on-windows.shtml
So, I went to upgrade from 14.1 and saw there is now 14.3 and got that. when I try the environment variable instructions from the 14.2 post I get a message saying that is deprecated and now it should be JMP_PYTHON_MODULE_PATH. So I tried that, I think with a valid path to the right file, using same format from the 14.2 post, but still not working. Occured to me to try this in my JMP15 early adopter version as well and got same results, same message that the environment variable should be called JMP_PYTHON_MODULE_PATH.
In all cases (14.1, 14.3, 15 early adopter, various versions of environment variables) if I have no argument in Python Init(), JMP crashes right away on that line. If I have the UsePythonVersion("3.6") in there it comes back with an error saying it can't find Python at all..
An installation of Python cannot be found on this system. JMP Python support requires Python version 3.0 or higher. in access or evaluation of 'Python Init' , Python Init/*###*/(Use Python Version( "3.6" ))
Is anyone using this successfully? If so are you putting something inside Python Init()?
or if you used setting an environment variable what is it called and what does it look like? Any further troubleshooting advice?
Here's what my latest attempt at environment variable looks like... is this not the right format? (the earlier post looked like environment variable had curly brackets and double quotes like JMP wanted to see is as a JSL list format but this looks like what the 4.2 post is saying to do and other format didn't work for me either... A python36.dll file really does seem to be in this location... 
Not sure if I'm having a freak problem specific to my system that I need tech support on or whether I just don't get the latest verison of how this is supposed to work.
Re: JMP 14 Python abilities - working? I'm confusedUsing the environment variables was never the preferred route. The JSL Script parameters to Python Init() or Python Connect() were always 'supposed' to be the definitive values. All of the parameter are optional, but specifying path to the python3x.dll and as a last resort adding in the sys.path should fully specify the Python. The Python Integration has significantly improved the python detection since JMP 14. At this point use of the Environment variables is likely counter productive and should not be used, ( unless you have time to fiddle with knobs and all else fails, it's an alternate code path). In JMP 16.1 and newer the JSL script parameters 'should' override anything else...
Re: JMP 14 Python abilities - working? I'm confusedI know this is a bit late of a response but this topic needs to be edited and updated for newer versions of JMP and Anaconda. Please note I was successful in integrating python 3.8 with JMP 16 on 8/24/2021.
In direct contradiction to the "Solution" posted in this thread, DO NOT change any Environmental variables AT ALL.
DO.
NOT.
This "Solution" caused me to fail in my integration and development for several weeks. After installing JMP or updating JMP you should install a fresh version of Anaconda (Anaconda Navigator can be used) and be sure that your Base (root) Environment in Anaconda is at least 3.8.3. I have also tested with success on 3.8.8.
You can verify your pathing and installation by doing the following:
- Navigate to C:\Program Files\SAS\JMP\\ (if you don't see it here check: C:\Program Files (x86)\SAS\JMP\\)
- Double-click on InstallChecker.exe (It might just say Install Checker)
- After the report is displayed, choose "Open in Browser"
You should then see an XML file and at the end you should see the following:
-
"/>
"/>
"/>
"/>
"/>
In my case the integration was successful after I changed the Environmental Variables to:
"/>
"/>
I hope this helps and I would strongly suggest the solution on this thread be removed as it simply doesn't work.
Re: JMP 14 Python abilities - working? I'm confusedJMP 15.0 still suffers from the same issue. I installed the linked Anaconda without the PATH option and it worked.
Note that this package is quite old, so you will need to conda update your packages being careful not to go to update Python itself 3.6.5 (3.6.9 didn't worked for me).
I hope its fixed in next releases.
@FN wrote:
I can confirm that with Windows 10 and JMP 14.2 it works out of the box, if:
Anaconda Python 3.6* 64bit is installed > https://repo.continuum.io/archive/Anaconda3-5.2.0-Windows-x86_64.exe;
and the PATH option is activated (no admin rights required)
My point was more about the capability of deploying addins with a portable Python version so users do not need to hassle with the Anaconda installation, environments and versioning.
Thanks for the help. Looking forward to seeing a great Python integration in the following updates.
(*) With the current version of Anaconda, JMP crashes with this config.
Re: JMP 14 Python abilities - working? I'm confusedRegarding deployment, I think it will be fine as soon as Python does not interfer with other user installations.
For example, I am trying to call Python from JMP 15 EA8 which is in one specific folder.
This folder contains all the instalation files of Anaconda/miniconda, which I copied to a folder before uninstalling it. The code worked when it was installed. Now, it seems that JMP does not use the path I am specifying.
Set Environment Variable( "JMP_PYTHON_MODULE_PATH",
"\["", "C:/Users/xxx/JMP_scripting/python/miniconda3/python36.zip",
"C:/Users/xxx/JMP_scripting/python/miniconda3/DLLs",
"C:/Users/xxx/JMP_scripting/python/miniconda3/lib",
"C:/Users/xxx/JMP_scripting/python/miniconda3",
"C:/Users/xxx/JMP_scripting/python/miniconda3/lib/site-packages",
"C:/Users/xxx/JMP_scripting/python/miniconda3/lib/site-packages/win32",
"C:/Users/xxx/JMP_scripting/python/miniconda3/lib/site-packages/win32/lib",
"C:/Users/xxx/JMP_scripting/python/miniconda3/lib/site-packages/Pythonwin"]\"
);
Python Init (Path("C:\Users\xxx\JMP_scripting\python\miniconda3"),
Init Trace("TRUE"),
Debug Print Statements ("TRUE"),
Debug Print Output("TRUE") );
Python Submit( "\[basket = ["apple", "orange", "pear"]
print(basket)]\" );
Python Term();
Error in JMP 15 EA8
Error in JMP Pro 14.2:
An installation of Python cannot be found on this system. JMP Python support requires Python version 3.0 or higher. in access or evaluation of 'Python Init' , Python Init/*###*/(Path(
"C:\Users\xxx\JMP_scripting\python\miniconda3"
))
Re: JMP 14 Python abilities - working? I'm confusedNice! That is a great use case.
As you search for the ideal JMP + Python workflow, it is worth noting that JMP (Pro) can generate Python scoring code for JMP models. That supports integration in the other direction: pushing JMP capabilities into the Python world.
For example, say you wanted to apply a JMP model to a large data table in Oracle, you could convert the model to Python and score it in the database using UDFs (support seems to be experimental though):
https://oracle.github.io/oracle-db-mle/python/
Or you could share your JMP model with your Python colleague so that she could run it in a Jupyter notebook, and so on.
Also, JMP 15.0 will make it easier to display external images as thumbnails in your data visualization tooltips. That would reduce/eliminate the need to import them directly to your JMP tables, keeping them smaller. There is a performance cost of course, but it might be a worthy trade-off. Keep an eye out for that.
Thanks for sharing! Keep us posted on your journey!
Re: JMP 14 Python abilities - working? I'm confusedThis looks great - thanks! I don't have time to test it out for at least a couple of weeks (and I completely redid my Python install w/o virtual environment so will take some doing to try this) but I will be keen to test this out soon.
The thing that really jump started my Python use is classifying images with tensorflow and keras. I'm running a JMP script that queries up relevant images and calls python to run my model and then pushes results to Oracle. That entire task is something I will probably end up doing in Python but which I'm doing in JSL because I'm much more proficient in that so far - just learning in Python- and I already have a whole scheme for running JSL automated jobs, have functions built for pushing tables to our Oracle, etc.
However, while I thought that whole project would not be inherently JMP-related I actually found that having images in a JMP table alongside other data where they can be interacted with in all the usual JMP ways is really useful - sorting, selecting based on other data columns, etc.. That spurred me to do a number of other image-related addins. Remains to be seen whether in the end there's a true need in my project to call up the Python during a live interactive JMP session or they can be separate ( a tool that reviews tf model results interactively just querying up results from Oracle, not directly calling Python to run models live?) but I'm currently using them together.
Anyway, that's the not-in-JMP thing I'm using Python for now. I'm trying to learn more Python and have colleagues who are expert in it and I feel likely to find more things where I might like to actually call Python to join its abilities with JMP.
Thanks!
Re: JMP 14 Python abilities - working? I'm confusedHi there @hardner,
Good to know you have been using Python with JMP more. If you can share what you have been doing, we would love to know!
Regarding support for virtual environments, I hear you. It does make a big difference in terms of keeping your dependencies organized, AND helping your co-workers reproduce your environment in order to run your addins.
Which is why I put together a little library that helps with that very problem. Please check:
https://community.jmp.com/t5/JMP-Scripts/Anaconda-Environments-Integration/ta-p/221565
Lots of examples, tested in 14.3 and 15.1. But, at least for now, Windows-only and Anaconda-specific.
Let me know if it works for you!
Re: JMP 14 Python abilities - working? I'm confusedHello!
Just butting back into this thread as OP to say...
- I've been using Python more since my original post and what I said was working for me has continued to work. 
- I appreciate efforts to support Python, more so now I have found specific things to use it for. Thanks!
- Like FN I find sharing addins that call Python problematic. I do share a lot of addins. I'm using this now just for myself and for jobs that I run that then share outcomes with others but not in scripts to be run by others. I'd have to give complicated instructions on installing Python and packages and worry about the specific versions working together (same issue occurs with R which I use but not in shared scripts). But if a particular version were encapsulated within JMP it would limit what we can do with it. Still think maybe supporting virutal environments could help, then I could instruct and support users on setting up an installation to my specfications for a particular tool they want to use and not interfere with any other Python activities on their machine. But not really sure what would be best and not that keen to troubleshoot users Python installations. So just agreeing it's not ideal and noting I do have some interest in making more use of this ability.
Thanks!
Re: JMP 14 Python abilities - working? I'm confusedI can confirm that with Windows 10 and JMP 14.2 it works out of the box, if:
Anaconda Python 3.6* 64bit is installed > https://repo.continuum.io/archive/Anaconda3-5.2.0-Windows-x86_64.exe;
and the PATH option is activated (no admin rights required)
My point was more about the capability of deploying addins with a portable Python version so users do not need to hassle with the Anaconda installation, environments and versioning.
Thanks for the help. Looking forward to seeing a great Python integration in the following updates.
(*) With the current version of Anaconda, JMP crashes with this config.
Re: JMP 14 Python abilities - working? I'm confusedI'm not sure I understand your question. Installing Python for all users does indeed require admin access, but using the installed Python does not require admin access. A JMP add-in that called Python would not require admin access to install or run. Yes additional Python packages that are installed for all users would require admin access. You should be able to install site local packages on a per user basis that would not require admin to install. This is something I have been meaning to test, but have had a chance to try. It might require you updating the sys.path to add the location of the site local packages.
As for JMP 15 documentation, I know some of this discussion has made it in. Unfortunately, not everything has made it into docs before the cutoff. We'll work on getting the rest of it in through the maintenance releases.
Re: JMP 14 Python abilities - working? I'm confusedInstalling for all user also requires admin rights, which is not convenient when distributing an add-in that calls Python.
Will the documentation of JMP 15 include what has been discussed in here?
Re: JMP 14 Python abilities - working? I'm confusedWe were able replicate on a development machine, the sudden exit of JMP when trying to load Python 3.7. It turns out we (JMP) are not alone in having problems with Python 3.7, and Python 3.8 especially in an embedded case. The error we got from Python is:
Fatal Python error: unable to load the file system codec
Unhandled exception at 0x00007FFE84F9B64E (ucrtbase.dll) in Jmp.exe: Fatal program exit requested.
The solution at present, is to either use Python 3.6.5 or newer 3.6.x, or you have to install Python 3.7.x on Windows as an install for all users, not just you the local user AND you MUST choose the option to put the Python in your PATH. This directly contradicts Anaconda3's install dialog, warning about not putting it in the path.
My development machine works fine with 3.7.1 installed as a system wide install and is the default Python on the Path. My co-worker's machine where we were able to replicate the sudden abort of JMP, we installed Python 3.7.1 using the default install options which made a local install not on the path. We were able to keep JMP from exiting by setting the environment variable PYTHONHOME= 'the anaconda3 directory' But even here we couldn't get it to load numpy, scipi, pandas, or sqlite3, even from a console prompt. Where on my machine all works as expected.
Re: JMP 14 Python abilities - working? I'm confusedmore on UsePythonVersion("3.6"), just in case it's useful....
this line does not work when JMP is first opened...
Python Init(Use Python Version( "3.6" ), InitTrace( "True" ));
Here's what the log shows from the InitTrace()...
Processing OpPythonInit operator
Starting JMP to Python interface initialization
Query HKEY_CURRENT_USER
Reading hKey=0XFFFFFFFF80000001 kname=SOFTWARE\Python\PythonCore bits=64
Found hKey=0xFFFFFFFF80000001 kname=SOFTWARE\Python\PythonCore bits=64
# of subkeys=1
Retrieving subkey #=0
subkey=3.6 length=3
Opening subkey=3.6
Opening key=3.6 subkey=InstallPath
Query value key=3.6 subkey=InstallPath
Query value key=3.6 subkey=InstallPath value=C:\Users\12470\AppData\Local\Continuum\anaconda3
Opening key=3.6 subkey=PythonPath
Query value key=3.6 subkey=PythonPath
Building path to version=3.6 of the Python DLL
An installation of Python cannot be found on this system. JMP Python support requires Python version 3.0 or higher. in access or evaluation of 'Python Init' , Python Init/*###*/(Use Python Version( "3.6" ), InitTrace( "True" ))
This happens repeatedly if I run the line over and over but if I do this version without UsePythonVersion...
Python Init(InitTrace( "True" ));
Not only does it work, but after that the original version with UsePythonVersion("3.6") argument starts working too, while this JMP session is open. Here's what the log shows from that init trace in that case. path showing there look same and correct to me in both cases....
Query HKEY_CURRENT_USER
Reading hKey=0XFFFFFFFF80000001 kname=SOFTWARE\Python\PythonCore bits=64
Found hKey=0xFFFFFFFF80000001 kname=SOFTWARE\Python\PythonCore bits=64
# of subkeys=1
Retrieving subkey #=0
subkey=3.6 length=3
Opening subkey=3.6
Opening key=3.6 subkey=InstallPath
Query value key=3.6 subkey=InstallPath
Query value key=3.6 subkey=InstallPath value=C:\Users\12470\AppData\Local\Continuum\anaconda3
Opening key=3.6 subkey=PythonPath
Query value key=3.6 subkey=PythonPath
Building path to version=3.6 of the Python DLL
Python DLL path=C:\Users\12470\AppData\Local\Continuum\anaconda3\python36.dll
sys.path entry.jstr:C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\Lib
sys.path entry.jstr:C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\DLLs
BEFORE:
/**********/
print(_JMPsys.path)
/**********/
['C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\python36.zip', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\Lib', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\DLLs', 'C:\\Program Files\\SAS\\JMP\\14', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\Babel-2.5.0-py3.6.egg', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\win32', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\win32\\lib', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\Pythonwin']
AFTER:
/**********/
print(_JMPsys.path)
/**********/
['', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\python36.zip', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\Lib', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\DLLs', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\win32', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\win32\\lib', 'C:\\Users\\12470\\AppData\\Local\\Continuum\\anaconda3\\lib\\site-packages\\Pythonwin']
Re: JMP 14 Python abilities - working? I'm confusedWorking!
Here's what worked for me:
I reinstalled Anaconda using an archived one meant for Python 3.6 (to avoid using a virtual environment for 3.6). Here's where it installed, same as previous just without 2 more layers for virtual env under anaconda3 folder):
C:\Users\12470\AppData\Local\Continuum\anaconda3\python36.dll
Set environment variable JMP_PYTHON_MODULE_PATH to the above path for python36.dll
Did not use UsePythonVersion("3.6") argument in python init(), that gives the "installation cannot be found" error.
Nothing I'm trying after the reinstall is, so far, causing a crash. Admittedly haven't done much but appears that it was something about the virtual environment that was causing crashing (?). Limited testing I've done so far is working in both 14.3 and the 15EA.
Thanks!
Re: JMP 14 Python abilities - working? I'm confused@Paul_Nelson & @Jeff_Perkinson ,
Updated JMP to 14.3 and can confirm that crashing still continues. Let me know if there is any further information you need.
Re: JMP 14 Python abilities - working? I'm confusedThe very first thing you should to do is to update to a newer version of JMP 14. The original 14.0.0 worked fine if it could automatically detect the proper Python installation. But, if it couldn’t correctly locate Python, none of the other methods worked well at all. The work in the successive updates 14.1, 14.2,… have made the other alternatives work better, the checking environment variables, the use of the Python Init() variables. It still may not work in your specific environment, but this the first place to start.
You should continue to work with JMP’s technical support. By going through technical support, all JMP customers benefit by what we work out on this issue. At the moment it’s going to take some more digging in the code, some additional instrumenting of the code and some additional bullet-proofing of the code, it may even take writing a test or diagnostic program.
Thanks for your patience.
Paul
Re: JMP 14 Python abilities - working? I'm confusedFor what it's worth mine are definitely both 64 bit and I get the crashing as well. The only time mine doesn't crash on Python Init() is with the Use Python Version() argument when I get the "can't find" message.Re: JMP 14 Python abilities - working? I'm confused@hardner and @Paul_Nelson ,
Paul,I can concur with @hardner 's observations. Is it ok to ask you to do a webex with us may be tomorrow or maybe next week, what ever works for you, where you can look at our installations and tell us why it is not working ? You can then probably publish a renewed Blog article on the community based on the learnings we take away from the meeting ? Is this something you could do ?
Re: JMP 14 Python abilities - working? I'm confusedFor what it's worth mine are definitely both 64 bit and I get the crashing as well. The only time mine doesn't crash on Python Init() is with the Use Python Version() argument when I get the "can't find" message.
Re: JMP 14 Python abilities - working? I'm confusedI would also update to the latest version of JMP 14. Additional work was done in each version of JMP 14.x to improve finding Python and properly loading it.Re: JMP 14 Python abilities - working? I'm confusedI was hoping for a mismatch and your problems would suddenly be solved.
I have just added additional code to catch exceptions when we try to load Python. I will also look at adding code so the Init Trace(“TRUE”) writes to a file as well as the log so that we can get some trace of the execution path for Python initialization. Hopefully both should be in the next JMP 15 EA. (not sure when the next one is due).
Paul
Re: JMP 14 Python abilities - working? I'm confused@Paul_Nelson ,
Indeed. I have checked and validated that both JMP and Python are both 64-bit.
Re: JMP 14 Python abilities - working? I'm confusedHave you verified that your Python and JMP are the same bit-ness. 32-bits or 64-bits. The lack of a dump file indicates JMP is probably going down when it tries to load Python as a shared library. If there is a mis-match 32-bit JMP / 64-bit Python or 64-bit JMP / 32-bit Python, would pretty well guarantee a crash.
That’s something JMP should try to validate before attempting to load, and something that we should be attempting to catch, but it might still be an unrecoverable condition. But it would be good if JMP could give some notification.
Paul
Re: JMP 14 Python abilities - working? I'm confused@Paul_Nelson ,
I have on ongoing case with Tech Support on this issue - SAS 7612709398.
I have tried to include the trace as you have suggested and that crashes Jmp. However, I don't see a .dmp file or .jer file being generated that I can provide to Tech suppport.
Re: JMP 14 Python abilities - working? I'm confusedSupporting python virtual environments is something we are looking at.
The flip-side is this question:
Is supporting the varitey of user installed versions of Python is too difficult to get running and keep running?
If so, the solution may be a JMP supplied and installed version of Python that is tested and known to work with JMP without issue. The problems that brings include supporing the install of local packages and extension into a JMP delivered Python environment.
At the moment we would prefer to support the user's installed Python, but as you have experienced the variety in the wild can make that a challenge.
Thanks,
Paul
Re: JMP 14 Python abilities - working? I'm confusedThanks for all this.
Pretty sure of the things you mention my issue is "JMP at present is not aware of virtual environments".
Having installed Anaconda latest with python 3.7 in it, then finding I want to use tensorflow requiring 3.6, I did the first of the options described here...set up a python3.6 environment.
https://docs.anaconda.com/anaconda/user-guide/faq/#anaconda-faq-35
Given I'm just getting going with python and don't have a special need about 3.7 - that I know of - I think I might uninstall all of it and start over with another of the options, like an archived Anaconda install package with 3.6. I'll see how that goes.
But seems like this kind of "need different versions for different stuff" is common, as it is for R - it was reading that was the case that made me dive into that more complicated-looking option and the link above wasn't the only place I saw the advice to use a virtual environment. So wondering if you can say any more about plans to be able to tell it to operate in a particular virtual environment.
The InitTrace("TRUE") thing crashes JMP for me. But maybe if I didn't have my path involving a virtual environment it would be different. Will work on that and open a Tech Support case for further help. Thanks!
Re: JMP 14 Python abilities - working? I'm confusedI know it's as frustrating for us as it is for you. We are having a hard time replicating the issue on our machines, yet we do know there are some customers having issues. Most of our are machines are similar, with the same corporate image... One thing that is important, the bit-ness of JMP and Python must match. Because JMP loads Python as a shared library you cannot mix JMP and Python with different bit-ness. If you have 32-bit JMP you must be pointing to a 32-bit Python 3.6.1 or newer. If you have 64-bit JMP it must be a 64-bit Python 3.6.1 or newer. We found the very best chance of success if you only have a single installation of Python on your system. In JMP 14.1 if there was more than one on the system, it wouldn't even try to load Python. JMP at present is not aware of virtual enviroments.
Those having troubles please try the following option in your Python Init()
Python Init( Init Trace("TRUE") );
This option, likely not documented (sorry), will cause JMP to dump out a lot of detail on where it thinks Python is located including paths it sees and registry entries for Python that it discovers. Please include it's output when contacting tech support.
You can determine what bit-ness your running the following Python script in your environment
import struct
print( struct.calcsize("P") *8)
This should print 32 or 64 based on the bit-ness of the Python running.
Note: JMP 14 could be either 32-bit or 64-bit depending on the version. Shrink-wrap is always 32-bit
JMP 15 is only 64-bit.
I'll try to document to the fullest the Python Init() and the environment variables.
JMP 15 adds 2 new environment variables that it is looking for:
JMP_LIB_PYTHON_PATH - this is the full path to the shared library.
JMP_PYTHON_MODULE_PATH - Python's sys.path as one would expect in Windows or MacOS enviroment variables. On windows a semi-colon separated list, on MacOS a colon separated list, NOT a JSL list.
On my machine I have Anaconda 3.7.1 64-bit installed in C:\ProgramData\Anaconda3
that would look like
JMP_LIB_PYTHON_PATH=C:\ProgramData\Anaconda3\python37.dll
The path to the dll should be enough... and should be sufficient that Python Init() can be used without parameters. With the JMP_LIB_PYTHON_PATH and JMP_PYTHON_MODULE_PATH specified, Python should be fully specified even with more than one Python interpreter and Python Init() should just work.
As discussed 'Python sys path' as an environemnt variable was deprecated because it doesn't follow normal conventions for shell environment variables on either Windows or MacOS. It has spaces in the variable name and it expects a JSL list of path components { , } NOT the expected colon delimited paths on UNIX or the semi-colon delimited paths expected on Windows.
We have made an attemp to pay better attention to the Python enviroment variables PYTHONPATH and PYTHONHOME. From the Python documentation the description of these variables is:
PYTHONHOME
Change the location of the standard Python libraries. By default, the libraries are searched in
prefix/lib/pythonversion and exec_prefix/lib/pythonversion, where prefix and exec_prefix are
installation-dependent directories, both defaulting to /usr/local.
When PYTHONHOME is set to a single directory, its value replaces both prefix and exec_prefix.
To specify different values for these, set PYTHONHOME to prefix:exec_prefix.
PYTHONPATH
Augment the default search path for module files. The format is the same as the shell's
PATH: one or more directory pathnames separated by os.pathsep (e.g. colons on Unix or
semicolons on Windows). Non-existent directories are silently ignored.
In addition to normal directories, individual PYTHONPATH entries may refer to zipfiles
containing pure Python modules (in either source or compiled form). Extension modules
cannot be imported from zipfiles.
The default search path is installation dependent, but generally begins with prefix/lib/pythonversion
(see PYTHONHOME above). It is always appended to PYTHONPATH.
An additional directory will be inserted in the search path in front of PYTHONPATH as described above
under Interface options. The search path can be manipulated from within a Python program as the variable sys.path.
The order of precedent that JMP 15 looks for the environment variables:
Order of precedence of the Environment variables and JSL script highest to lowest
- Specfied within the JSL script in Python Init( Path(""), Use Python Version(""), Python sys path( { "",... } ), ... )
- Specified in the System/Shell Environment variables
- Auto located
- Registry, found on PATH var, or System shell to run python or conda, ... and should prefer a locally installed Python
over a system wide install Python if both exist
JMP 14
Looked first at the environment varialble 'Python sys path' which could be either the path to the dll, or the full sys.path expressed as a JSL list {"","",... }
PYTHONINSTALLPATH = the path to the top level directory containing the python installation, or the directory containing the Python shared library.
The Python Init() statement
Parameters:
Path() - The full path to the dll, or Python top level directory containing the dll.
Use Python Version() - quoted string of the major.minor python version. Often sufficient on it's own when more than one Python is found.
Python sys path() - the JSL list of quoted string paths that correspond to the Python sys.path value. Specifying these 3 should completely specify the Python installation and should override any Environment or registry values.
Init Trace("TRUE") - debugging output during JMP's Python initialization to JMP's log
Debug Print Statements ("TRUE"); - directly print the Python statements to the JMP log
Debug Print Output("TRUE"); - directly print Python output to the JMP log
JMP 14 Python Init() also optionally accepts the following: Use only one or the other, and matching the bit-ness of your JMP installation. 32-bit JMP cannot use 64-bit Python and 64-bit JMP cannot use 32-bit Python.
Use 32 Bit Python("TRUE")
Use 64 Bit Python("TRUE")
JMP 15 removed the above optional parameters since JMP 15 is 64-bit and can only use 64-bit Python. All of the parameters to Python Init() are optional, If the auto detection in the registry, or the Environment varialbles point to a valid Python, nothing further should needed in your Python Init()
Please don't hesitate to contact JMP's Technical Support, we want the Python capabilities in JMP to be useful and enhance the power that JMP provides. We want to sovle these issues so that it just works.
Paul
Re: JMP 14 Python abilities - working? I'm confusedfollowing...
Re: JMP 14 Python abilities - working? I'm confusedThanks! will do. I can only add that I also tried putting path() of dll inside python init() and that also crashes instead of at least just complaining it can't find it. Overall I probably need Technical Support help too, but was hoping there was just some clarification that would be useful to others too.Re: JMP 14 Python abilities - working? I'm confusedI can confirm that despite installing my anaconda distribution in C:\ and setting up an enviroment variable as detailed in the post, I am unable to get it to work. It still crashes JMP. I will update you if I get an answer from Technical Support, if you figure it out, kindly do the same
Re: JMP 14 Python abilities - working? I'm confused@hardner ,
I am in the same boat as you. I have been trying to configure JMP for Python for about 2 weeks now. I have successfully integrated with SAS and R from JMP, however the Python integration has been well unclear and drawn out to say the least. I am disappointed to know that JMP 15 early adopter does not have any improvements either to fix this integration. I was also closely following this post and was hoping that it will get fixed in JMP 15 and it will become smoother integration.
I am currently using JMP 14 and Python 3.7.1 . I have been advised to install Python/Anaconda distribution directly below the C:/ root and I am about to give that a shot. In case that works, I will give you a heads up on what worked and update here.
