Joerg Hampel

When adding contributors to VI Packages on vipm.io, the UI suggests that one can search for "vipm, github, and gitlab names": I tried that with one of my colleagues who is on GitLab but not on VIPM.io, but the search doesn't bring him up: Should this work?

Hey JKI team, is it possible to programmatically update an existing .vipc (or, alternatively, create a new one) with a given .vip file? Our use is case is the following: After building a .vip automatically, we'd like to install it to the very system it was built on automatically. Seeing as we already have a tool to apply .vipc files through the VIPM API, and as we could use it "as-is" for this, we'd prefer to install the .vip this way. Thanks for the great tool, Jörg

Yes, please, that would be great!

Jim, as always, your elaboration is spot on. Here's a screenshot of what our tools do: So other than the fact that we write all the build numbers in one go (the whole cluster), it's what you described above. Thanks for taking the suggestion into consideration.

With VIPM 2020.3 (build 2540) and VIPM API 2020.0.2.73, it's not possible to supply a major number of 0 via the API, the API returns an error 42: Seeing as we also build projects that are in a pre-v1.0 state, I don't see a reason to not allow the major build number to be 0. I was actually tempted to file a bug report... 😉

I tried starting VIPM by double-clicking the "VI Package Manager.exe" file in Windows Explorer, and it just came up alright! The error logs folder doesn't show anything (i.e. no files). The File Handler still doesn't start VIPM. Currently, this (legacy) machine has .NET Framework 4.6.2 installed. I just upgraded to v4.8 - that didn't change anything. Would you expect v4.8 to be new enough?

For one of our customer projects, upgrading from v1.0.2 to v1.1.0 resulted in an error when trying to build an executable from the project (downgrading to v1.0.2 fixed the build): I understand that we need to tidy our customer's project, having Caraya dependencies in the build is not what we want. The reason I'm posting here is that I'd be interested in understanding why this VI would break the build. Thanks, Joerg

Adding to the error description above, we are not able to uninstall or repair the VI Package Manager 2021 Pilot installation. Installing older versions of VIPM doesn't work either. Currently, this build server is "bricked". Is there anything else we can try on our side? Any log files we can provide for further analysis?

I installed the latest VIPM version (build 2694) one of our build machines running Windows 7. After rebooting, VIPM won't start - it shows in the task bar but seems to be stuck?

Yes, after manually changing the LabVIEW version inside the .dragon file to 2016 in Notepad++, it now shows the LabVIEW project view correctly: As a side note, when Dragon started to open/compile the LabVIEW project, it opened a blank new VI. This blank VI thingie seems to be a phenomenon on this new LV2016 VM, probably not related to Dragon...

Jim, what I meant to say is that after choosing not to install the required packages, although the navigation on the left side shows the project view icon highlighted, the window itself still displays the tree of resources (packages) instead of the "LabVIEW Project" - it doesn't show the VIs etc. project tree not showing.mov Maybe it has to do with the fact that this project was maintained in LabVIEW 2014 and I'm now trying to open it in LV 2016 for the first time? The .dragon file still has 2014 defined, as has the .lvproj file. If I choose to install the packages, but then deselect all of them, Dragon remains in a state that shows all the packages "disabled", and the status on the bottom says "VIPM: User Confirmation Dialog": package list greyed out.mov

Interestingly, suggestion (B) didn't work for me as the Package Manager would not show the other versions in the bottom left corner. Not sure what I did there. Could it be due to the fact that the package wasn't installed (i.e. cached) yet?

When opening a .dragon file and choosing not to install required packages (i.e. clicking the "No: ..." button), the UI is not updated and the project view shows the list of resources.

The attached example project doesn't show the lv-venv palette for the two locally installed packages. Also, for the second package, there was an error message after installing it: community-scope.zip May this has to do with the fact that the .dragon file is not located in the same folder as the .lvproj file?

Is there an easy way to install older versions of packages? The search window only offers to install the latest version through the Install button. The only way I could find was to open the VIPM by clicking the Dragon icon and then selecting "Open VIPM" to get VIPM to show the project scope...

After installing a package locally and switching to the file/project view, Dragon asks to install the LabVIEW CLI: I'm not sure what operation I (accidentally) triggered?

When clicking the "Add Package" link in the Project Dragon window, and the window itself is close to the bottom of the screen, the small search window is opened out of sight: add package.mov (Sorry for the size - I can't figure out how to scale media once inserted here)

😅 Thanks for looking into this. I'm not an LVOOP expert at all, so when I say "I can't think of any other types, either" it doesn't mean a lot I fear.

With the latest version of VIPM (2021.0 build 2696), the VI Package Builder reports friends of a library as missing even though those friends are not used in the code that's built. In the small example I attached, I created a class "TheClass.lvclass" which has one method "SomeSharedFeature.vi" which is set to community scope. Another class "TheFriend.lvclass" uses this method, and is therefor defined as friend in "TheClass". All the LabVIEW files are located in the /source folder. I created a source distribution to export "TheClass" to another place, a folder named /build (mainly because the original project where this error occurred does the same). When I use "community-scope.vipb" to build a package, everything works as expected. But when I remove or rename the location of "TheFriend" (eg rename /source to /___source), then VI Package Builder complains about missing files: community-scope.zip

We use G-CLI to execute our CI tools, so we'd write back to G-CLI (and also to the front panel of the tool in case we run it manually). So the point would be to get the progress information back into the VI that's actually using the VIPM API. vipb.mov

Building a VI package can take quite a while. For our Release Automation Tools, it takes about 20 minutes. Even though we build our packages on the build server now, it would be great to be able to feed back the progress of the build process to the CI system. As an example, the NI Application Builder API offers "progress bar" events, which you can register for and then show the progress details as you see fit: The VI Package Builder shows at least a few pieces of progress information in its status bar. Maybe these could be "routed" back to the VIPM API?

Thanks for elaborating. I agree with your thoughts, I had the feeling that .dragon and /lv-venv/ are similar to .vipc and .vipb and how we treat them. Browsing for the files was intuitive, and even just looking at the .dragon file in a text editor and changing the paths there felt natural to me. And yes, if all works out and we don't run into any further problems, I'm definitely planning to migrate our hse-libraries into separate VI packages which we then can install into each project directory as needed. (I'm also looking forward to being able to supply palette support which will help new users getting familiar with our libs).

Our usual repository structure has a directory /Source which contains the LabVIEW source code and also the .lvproj file. Other resources like .vipb or .vipc files usually live on the root directory of the repo. See the attached screenshot. I'm wondering if you have and thoughts about where the .dragon file and the /lv-venv/ directory should live: In the repository root together with .vipc and .vipb, or alongside the .lvproj file and LabVIEW source code in the /Source/ directory? Do you see any issues or benefits with either location, from a Project Dragon point of view?

Thanks for getting back so timely 🙂 No, we only installed Project Dragon today and I'm starting to think about the whole process/lifecycle, hence my question. But seeing as we build all the projects we host ourselves through CI, there will be an immediate need for the server side support once we start using the lv-venv. In the meantime, it would probably be ok if the .vipc on the build server is just installed to regular LabVIEW vi.lib. Would that work with the current version (i.e. is this the default or fallback behaviour)?

Jim, how will this differ from applying a .vipc file? Or, put differently, would applying a .vipc file programmatically in a repository that also contains the .dragon file (and the /lv-venv directory) not install the necessary packages in the predefined places?