Distribute VI package configuration

[Vollinger]

Hi,

I would like to ask for a help with the following issue: I am trying to distribute VIP file with some dependencies, which are not published on VIPM. Hence, I added them to VIPC and would like to distribute this VIPC with VIP file. Is this somehow possible?

[James@Work]

Howdy V,

I have not previously done exactly what you are asking, but have done some similar tasks. 
We use VIPM Pro and a local repository to distribute packages not found in the public repositories; not only our internally developed packages.

First, using VI Package Builder's Destinations and Source File Settings pages you can easily include the file and specify where it is installed.  Second, using the Custom Actions you can specify a VI to run Before or After the package install.  Use the Generate VI button to create a template VI and save into your package project; I create a Custom Actions folder when needed.  Edit this template VI to launch your package configuration file; I typically rename so I know its purpose without viewing.  You can use the System Exec.vi and create a constant for the command line that will include the exact install path to the .vipc file location.  And, if you're not comfortable with command lines, using Open a Document on Disk.vi is another option.

I'm uncertain of whether VIPM will have any issues launching a package configuration before or after a package install.  However, testing this will be simple and you can include instructions for the end-users if the automation is unsuccessful.

NOTE: My suggestions are based upon a Windows OS install and will need modifications for MAC or Linux

Best wishes with finding a solution.

James

[Jim Kring]

@Vollinger: Great question!

First, I was going to suggest the possibility of distributing a VIPC file (instead of a package) that includes your package and all it's dependencies inside of it. You can then name this VIPC file to convey that it's your package+dependencies. However, this approach doesn't fully look like an installer for your package -- it appears like a multi-package installer to your users. However, it's a pretty clean approach that involves distributing only a single file. And, you can name this VIPC file to convey that it's the installer for your product.

Another approach is to build the dependencies into the package file (if you remove the dependencies, then the package builder will pull in copies of those VIs and namespace them such that they are internalized inside the package). This makes your package file larger, since it now includes the dependencies and you also have to consider the licensing terms of your dependencies.

@James@Work: That's a very clever idea to putt a VIPC file inside the package as a support file. I'd love to hear how this works in practice.

Some considerations with this approach that come to mind:

- Dependencies are typically installed by VIPM before the package that depends upon them, and the package's installed contents are only available after the package is installed. So, the VIPC would need to be invoked *after* the package is installed (in a post install custom action).

- This approach makes the package file larger (since the package contains its dependencies).

- Some consideration may be needed about whether to install the bundled packages, if newer versions are already installed or happen to be cached/available.

- Deadlock issues may occur if a post-install tries to invoke the VIPM API to install packages, synchronously (since a package would try to install packages, which require VIPM to be idle, but it's not idle, because it's installing a package).