Include third party dependencies (JKI State Machine) with project for other computers?

[DoctorAutomatic]

I have a project in which I'm using the JKI state machine. I'd like for it to be possible for anyone else to go in the project folder, open the project, and be able to use it. The problem is that the JKI dependencies are somewhere else and you just get a bunch of file dialogs/errors when opening the project on a different machine that doesn't have the JKI SM addon installed (obviously, I'm trying to avoid everyone having to install the addon for my project and just have it always included within my project folder like every other vi).

I don't know what the best/safest way to do this is. I don't know what implications there are for doing it one way or another. It would seem to me this must be a common pain point but my searches aren't turning up very relevant discussions. I DON'T want to include all the dependencies that can almost always be counted on being present on a LabVIEW machine, I'm really only concerned with 3rd party vi's like JKI state machine. From what I can tell, there isn't a licensing problem with doing this (correct me if I'm wrong), I just don't know how to actually do it.

[proland1121]

use VI package manager (VIPM) to make a package from your project.  Specify the dependencies such that they install at the same time as your project.  Distribute this package to your team members.

[Gregory]

Hi there, you have a couple of options.

With VIPM Pro you can create a VI Package Configuration. This does require people to install the .vip's to have all dependencies, but the configuration makes it so it only takes a couple of clicks. You can store this in source code control as part of your project.

If you don't have VIPM Pro, you can manually include the VI Packages. Go to the VIPM Cache to find everything you've installed. This should still be just a couple of clicks.

You can go to your LabVIEW project and create a new Build Specification which is a .zip file. This will include your entire hierarchy as it is seen on your disk (well, you have the option). This often has two large branches, one that digs into your project, and the other that digs into your user.lib. This is not good for source code control, but OK if you need to quickly send your code off for someone else to troubleshoot, at least they will be able to open it.

You will get a similar result to the .zip file if you instead go to file >> save for previous version... (you can actually choose your current version of LabVIEW so nothing gets converted). This will create a duplicate of your project hierarchy, but not zipped up.

What I do when I find a toolkit I like, is to save a copy of it, usually by putting it into a project if it's not already in one and doing the save for previous version as above. Then I uninstall the toolkit through VIPM, and manually put it in each project that I want to use it in. I often make some little tweaks to suit my needs as well. It's not so easy to update toolkits this way, but I find it makes more sense for source code control.

Also, MGI has started pushing their "G Package Manager" (more info at gpackage.io) which is project-based re-use code installation. This is in part to address the problem you are having to distribute your project source code without having to tell people how to get all the dependencies.