turbophil

This is with the latest v1.1.0.119 Thanks for looking into it!

We noticed that our CI process was executing individual Caraya tests that are defined in a Test Suite, but not running the Test Suite itself. In our particular case, it was noticed because we have a Suite that runs a bunch of tests in a parallel-for loop (mostly to cut down on total execution time, but there is also a slight confidence boost in seeing that there is no negative interaction between the VIs under test running in parallel). Upon investigation, we found that the "Discover Tests.vi" is explicitly excluding Test Suites from the results. There is a comment in "Find Test and Suite Index.vi" that gives a little hint as to the rationale: However, I still don't quite understand why we would want to exclude Test Suites. It's not necessarily a dealbreaker problem for the example of the call-tests-in-a-parallel-for-loop situation, since that's mostly just done to save time, but I could see a situation where someone might want to define tests to run in a particular order in a Test Suite, but then when automating it, they lose that explicit ordering. Is there a way to get the test discovery to respect Test Suite grouping? I suppose we could roll our own child class of TestRunner to implement this behavior, but before we go too far down that road, I'd like to make sure we're not reinventing a wheel (or risking reintroducing a problem that this exclusion is specifically avoiding). In my mind, I would imagine we could: Find all defined tests Find all define test suites For each suite found, check its linker info to find the tests it contains Remove those discrete tests from the list, as they are redundant with the test suite Similarly, if a given test suite contains other suites as dependencies, remove those, as well (also redundant) But, again, before I go too far down that path, is there already some other workaround for this problem? Or if not, does this sound like a viable solution? Thanks!

It appears I need to do the following: Kill the entire process tree for VIPM in task manager/process explorer Run VI Package Manager.exe as admin Then, after the splash screen, the window disappears, but the process is apparently still running Attempt to open a *.vip file, or in some other way try to force the main VIPM window to open Attempt to install packages I only appear to have about a 50% success rate with this series of actions. But if I go through the motions several times, I can usually eventually get it working. Would be nice if the basic functionality worked out of the box.

To be clear. Attempting to run C:\Program Files (x86)\JKI\VI Package Manager\VI Package Manager.exe as admin doesn't appear to work. The application never starts up. Presumably because now it is intended to be launched via some helper (perhaps it needs arguments?). I managed to make VIPM usable on my personal machine by setting the main VIPM executable *always* run as admin, but that means I'm greeted with an annoying prompt every time I run it (or restart LabVIEW). I'm trying to set up machines for our CI process, and they need VI packages installed to build some of our applications, and installations are failing due to this error 8 stuff. I can't set those to always run VIPM as admin, since I can't have them popping up dialogs every time LabVIEW is restarted.

Constantly running into issues with VIPM failing to install packages with error 8 messages. Seems like it needs to run as admin. Attempts to run VIPM as admin don't appear to work because it seems that now there is a lot of bootstrapping goin on (the main VIPM executable is launched via some background service and/or file browser helper utility?). Is there a set of streamlined instructions on how we can consistently get this tool to work?

I, too, would be interested in such a feature. It would make things really nice if we could export the list of installed packages from one machine and then import that on another to mirror the configuration. This would roughly approximate doing a "pip freeze" and generating "requirements.txt" for python code.

I, too, would be interested in such a feature. It would make things really nice if we could export the list of installed packages from one machine and then import that on another to mirror the configuration. This would roughly approximate doing a "pip freeze" and generating "requirements.txt" for python code.