Unpublished Dependancies

[GrahamB]

I've been able to make a set of packages which have dependencies between each other. I now would like to make a high level package which is empty except for a placeholder file that just has the other packages in its dependencies list (like OpenG) to make installation simple.

 

The problem is that these are all local unpublished packages and when I try to install the 1 high level package it pops up the "Resolving Package Dependencies..." message which appears to never end, forcing me to end the VIPM process to exit (maybe a bug?).

 

My assumption is that this is not possible without the Enterprise edition in which a published repository would exist to find the missing dependencies, and that right now the package just has no concept of where the other packages are. Is this correct?

 

If so, does this mean for the moment I'll have to install each package in the correct order manually to make sure the dependencies jive with each other?

 

We are using VIPM Professional (build 1692), if that is relevant.

 

Thanks!

Graham

[Michael Aivaliotis]

This is an excellent question. There are several sides to this story and I'll try to cover them all.

• Your proposed solution would only work if those dependancies are located either on a network repository (Created with VIPM Enterprise), the LabVIEW Tools Network or the VI Package Network.
• The "Resolving Package Dependencies..." problem is a known bug which will be fixed in a future release of VIPM. It is caused when trying to install packages that are missing dependencies.

There is another solution that will help you do what you want. Here is a link to the article:

 

How to use VI Package Configurations (VIPC)

 

 

Basically, you drop all of your packages into a VIPC file and then you can distribute this single file. VIPM will install all of the packages correctly.

[GrahamB]

I knew I should have looked into VIPC files before asking, for some reason I imagined VIPC files just being simple text files that listed packages and version. They are obviously much more than that. Looks perfect, I'll give it a shot today.

 

I'm curious now though, any suggestions on the best practices to implement what I want to do? Do I still need to bother managing a "high-level" package that lists the dependencies, or does the VIPC file just make this irrelevant now? I imagine the VIPC file replaces the need for this.. but since I'm a bit inexperienced managing more complex packages maybe you can offer a good methodology on this? Keeping in mind these packages will likely never appear on the LV Tools network or any type of public repository.

 

Thanks,

Graham

[Michael Aivaliotis]

If you create an internal repository and all the clients have access to it, then it's ok to create the toplevel package. It's helpful because the package can reside in a repository somewhere and can be accessed through VIPM. OpenG did this because it's convenient and allows for a single entry in the VIPM list to select and install all the OpenG packages. We currently have no way of "hosting" VIPC files, just packages. This may change in the future.

 

However, the best approach for your situation appears to be using VIPC files.