[New Feature] Improved Python Support

[Christina_R]

---

@Eisenwr wrote:

---

---

Is this feature expected to be used currently to help when python is not in the system path directories?

---

Yes, this feature should help when you want your VI to use a Python executable that is not in the system path directories.

[Christina_R]

---

@jj2 wrote:

Python returned the following error: Numpy package not installed.

I'm not familiar with the error that you're describing. Can you please provide more information?

1. What version of Python are you using?
2. What version of NumPy do you have installed?
3. Are you using 32-bit or 64-bit versions of LabVIEW and Python?
4. Are you using Python from within a virtual environment like Anaconda?
5. Is the issue specific to this example, or are you seeing this whenever there is NumPy code used?
6. If you're willing to share system information, I'd like to know:
   
   1. Operating system version
   2. Processor

[Yndigegn]

Nice to know that Python interface support is prioritized. Python is here to stay for better or worse.

But about deprecation. You write "deprecates support for Python 2.7". What does that mean ?

- Do you intend to completely remove support for 2.7 ?

- Or do you just freeze the support state for 2.7 as it is now, meaning no further developments ?

I assume you mean freeze. But just to be sure.

Regards

[Christina_R]

---

@Yndigegn wrote:

You write "deprecates support for Python 2.7". What does that mean ?

- Do you intend to completely remove support for 2.7 ?

- Or do you just freeze the support state for 2.7 as it is now, meaning no further developments ?

We're not intentionally removing any functionality related to Python 2.7, but NI won't officially support it with LabVIEW 2021 and later.

[cbutcher]

---

@jj2 wrote:

Labview 2021 example C:\Program Files\National Instruments\LabVIEW 2021\examples\Connectivity\Python\support\NumpyExampleModule.py returns error

Python Node in PythonNode_NumpyMatmul.vi<APPEND>

Python returned the following error: Numpy package not installed.

Tried debugging since numpy package is actually installed  using using the feature ShowConsoleForPythonNode=TRUE

and got this message

UserWarning: mkl-service package failed to import, therefore Intel(R) MKL initialization ensuring its correct out-of-the box operation under condition when Gnu OpenMP had already been loaded by Python process is not assured. Please install mkl-service package, see http://github.com/IntelPython/mkl-service
from . import _distributor_init

Installed mkl-service package as suggested by error message but no luck.

---

Wild guess, but any chance you're using a Ryzen CPU?

The error looks vaguely like the one you can get from lvanalys.dll, described here: https://forums.ni.com/t5/LabVIEW/error-loading-lvanlys-dll-in-Labview-64-bits/td-p/4009772/page/2

Could be entirely unrelated, in which case, sorry for the noise.

[ArtisanWaterCrafter]

Is there any documentation/could you provide details on what triggers the code 1671/"Python returned the following error: Numpy package not installed" error? I have a python build in a conda-packaged virtual environment that works great (including numpy and such) when called from the command line, but is returning that error when I try to pass in a numpy array. I'd like to see if I can get this environment to play nicely (I can with Enthought-exported builds, just not Anaconda), and it would be helpful to understand what LabVIEW is actually looking for when it checks for numpy so that I can recreate and resolve the issue in my environment.

[ArtisanWaterCrafter]

---

@ArtisanWaterCrafter wrote:

Is there any documentation/could you provide details on what triggers the code 1671/"Python returned the following error: Numpy package not installed" error? I have a python build in a conda-packaged virtual environment that works great (including numpy and such) when called from the command line, but is returning that error when I try to pass in a numpy array. I'd like to see if I can get this environment to play nicely (I can with Enthought-exported builds, just not Anaconda), and it would be helpful to understand what LabVIEW is actually looking for when it checks for numpy so that I can recreate and resolve the issue in my environment.

---

After digging into this a bit more, I think what I'm really asking for here is just virtual environment support. To elaborate a little,

• My distributed VENV has a batch file wrapper that just A) actives the VENV, and B) calls python.exe w/ the provided arguments. Other tools (specifically, Enthought's toolkit) can use this as a drop-in replacement for python.exe, so I don't need to worry about the environment that LabVIEW itself is running in
  • Activating the environment really just consists of setting a few environment variables and adding some stuff to PATH so that numpy/mkl DLLs are found
• I can entirely circumvent the issue noted above if I activate my python virtual environment from a command prompt, call labview.exe from that same prompt, then run my vi (i.e. all of labview is being run in the virtual environment, including my python calls). This is inconvenient to configure for deployed applications
• It doesn't look to me like the LabVIEW Python node in the 2021 beta is actually calling the provided python.exe; would I be correct in guessing that it's actually just loading the python.dll adjacent to the provided executable and making library function calls?

[asbo]

Hey @ArtisanWaterCrafter - I tried to PM you, but you have private messages disabled.

This isn't a general support board, this is specifically about feedback on an upcoming release of LabVIEW. I recommend you delete these posts and make a new thread for yourself under the general LabVIEW support board (https://forums.ni.com/t5/LabVIEW/bd-p/170). You'll get a lot more visibility to get your question answered.

@Christina_R Sorry for the long delay in getting back to you, but I kept thinking I would have more free time to dig into this and didn't - happens to the best of us, right? Yes, the console window exposed by the INI setting is a big part of what made my debugging via TestStand instead of LabVIEW more productive; in LV, I ended up writing a simply logger to get information out, which lengthens the debug process. I know that some people think it's a little icky to have console windows pop up from external dependencies, but it really makes sense to me in this case.

I don't think it works well as a global setting - I'm guessing it is right now just because it's not a 'real' feature - but it would be perfect as a flag into Open Python Session (a bit like how System Exec allows you to conditionally show/hide the child process). I could see situations where you might just want it on for debugging, or where the application could have one python session used for feedback to the user and others that do background work without needing to be visible.