BookmarkSubscribe
Choose Language Hide Translation Bar
hardner
Community Trekker

JMP 14 Python abilities - working? I'm confused

I'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... env variable issue.png

 

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Re: JMP 14 Python abilities - working? I'm confused

I 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

  1. Specfied within the JSL script in Python Init( Path(""), Use Python Version(""), Python sys path( { "",... } ), ... )
  2. Specified in the System/Shell Environment variables 
  3. 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

28 REPLIES 28
uday_guntupalli
Community Trekker

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. 

Best
Uday
0 Kudos
uday_guntupalli
Community Trekker

Re: JMP 14 Python abilities - working? I'm confused

I 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 

Best
Uday
hardner
Community Trekker

Re: JMP 14 Python abilities - working? I'm confused

Thanks! 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.
0 Kudos
cwillden
Super User

Re: JMP 14 Python abilities - working? I'm confused

following...

-- Cameron Willden

Re: JMP 14 Python abilities - working? I'm confused

I 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

  1. Specfied within the JSL script in Python Init( Path(""), Use Python Version(""), Python sys path( { "",... } ), ... )
  2. Specified in the System/Shell Environment variables 
  3. 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

hardner
Community Trekker

Re: JMP 14 Python abilities - working? I'm confused

Thanks 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!

0 Kudos
Highlighted

Re: JMP 14 Python abilities - working? I'm confused

Supporting 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

0 Kudos
uday_guntupalli
Community Trekker

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. 

Best
Uday
0 Kudos

Re: JMP 14 Python abilities - working? I'm confused

Have 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
0 Kudos