Directly specify python.exe path in "Open python session.vi"

[jim86]

In Enthought's python integration toolkit (PITL), the "Open python session" VI accepted as an input the path to the python.exe file to use for the python kernel. In LV2019  the "Open python session" accepts a string "2.7" or "3.6", and then labview searches the system path to find the python installation.  The LV2019 method is vastly inferior to the PITL method. Due to the way the LV python node requires one to manipulate the system path in order to find the desired python installation, I realized that this is a complete non-starter for sending compiled applications to end users, because the end user may have multiple python installations on their computer, and I can’t expect them to bend over backwards just to be able to use my compiled LV app.

I do not know how NXG currently handles this, but I hope that they emulate the PITL method. Furthermore, it would be great if NXG could handle arbitrary python distribution, such as Anaconda, rather than just the bare bones installation from python.org. It would also be great if there was more documentation about the python node in general--there is very little to be found currently. The Labview python node is shrouded in mystery (e.g. what the heck is NIPythonInterface.exe) whereas the PITL was very self-explanatory. It is a shame that NI displaced such a useful product and replaced it with an inferior one.

[-----------------------]

I agree with this idea and hope NI hears it out despite the somewhat less-than-constructive tone.

While I don't think NI should try to support all the varieties of Python installations, an option should be available to allow the developer to specify a path to the interpreter's directory, if that is all LabVIEW needs to run the Python node. If more is needed (e.g. registry edit), that should be documented so the developer can handle it in order to use a non-standard installation.

For LabVIEW developers that deploy their programs as built Windows executables, I think the best approach to support the Python node is to include the embedded Python distribution with the LabVIEW application, as described here:

https://docs.python.org/3/using/windows.html#embedding-python

Pushing out an application directory containing the interpreter and any script dependencies seems more practical than maintaining a separate Python installation on the user's computer. So I support either changing the Python integration to allow the use of the embedded distribution or providing more documentation on what exactly LabVIEW needs to see for the integration to work.

[-----------------------]

Not sure this will help the original poster, but here is more information about what LabVIEW needs in the environment for the Python node to work:

https://forums.ni.com/t5/LabVIEW/Using-the-Python-Node-with-Other-Python-Installations/td-p/4083982

I actually deleted Python from my PATH, and with the registry keys set as described in the post, the Python node still worked for me in LabVIEW 2020.

[AristosQueue (NI)]

LV R&D likes this idea. We missed this use case in our design.

We are unlikely to work on this idea in the next major release cycle because of competing priorities, but the one after that, it will be a priority. I realize that two years is likely too far away for your needs. If Enthought's toolkit works for you, I encourage you to use it.

[-----------------------]

Thanks AristosQueue!

In case it helps anyone else, my plan to work around this issue in the meantime is to add registry keys (see earlier post) during my app's installation that will point to the embedded interpreter included in the application directory. To avoid any possible conflicts with another Python installation, I will call the key '3.emb-32' rather than '3.8-32'. After changing the embedded DLL to match (python3emb.dll) and wiring '3.emb' to the Open Python Session VI, I was able to get the Python node to run in 32-bit LabVIEW 2020 with this configuration.

Not ideal, but solves the problem for me until the new LabVIEW feature is released.

[jyoung8711]

This was one of the first things I noticed missing from the Python integration.  Being able to support "different python paths" would be able to spin up different environments per call... for instance having a python plugin interface that can call different installations with differing packages pre-installed... With python package versions changing very frequently in some cases, this can be pretty challenging.

The above suggestion of using a key "3.emb-32" is quite clever, so thanks for that temporary work around.  That is a great temporary solve to one of the issues I've been having along these lines.

[wiebe@CARYA]

Seems to be 'in development' to me?

[New Feature] Improved Python Support - NI Community