NI Package Manager Ignores Dependency

[GreyGrey]

When building a package via the application builder, you are only building the items that you have put inside your package. The dependencies section of the package builder just outlines the the other packages that your package will require as metadata however it does not serve the dependencies up. If you are hoping to deploy that package to another machine, the recommendation would be to create a feed that contains all necessary packages using the NIPM CLI, register that feed on other machines and then install. 

However, if the RTE was listed as a dependency, I wouldn't expect a user to be able to install it since a required dependency wasn't met. Can you provide the Package (or a test Package) here or in a DM so that I could take a look at it?

[Gregory]

Hi Brandon,

I am using the feed manager GUI in LV 2016 to manage my feed. I understand that the RTE is not part of the package (which is nice, because the package builds very quickly), but I would expect that the standard components from NI would be downloaded and installed automatically when listed as a dependency, correct? I will send you an example of the package I am installing.

[Hooovahh]

Yeah I too am interested in hearing NI's justification for this behavior.  If you've used any package manager you know what it means to be a dependency of a package, and resolving package dependencies is probably the first bullet point in package manager software.  I shouldn't have to make a custom feed for an application, and I shouldn't need a custom feed to install dependencies.  I know NI's already heard this many times from other people but "Just make it work like VIPM".  (sorry)

[APena]

Hi All,

gregoryj - If your application package has a required dependency on the LabVIEW RTE package and it is not available in a connected feed (either in the same feed as your application package or some other connected feed), then NIPM should not allow your application package to install. Can you please run the following command line command on a machine with your application package installed?

"C:\Program Files\National Instruments\NI Package Manager\nipkg.exe" info-installed <yourpackagename>

Specifically, I'm curious to see if the "Depends:" field exists and, if so, what it lists as its dependencies.

hoovah - I want to make sure I understand your comment/suggestion because I think there are a couple ways we could approach a solution.

One way is through a "package installer" which, as the name implies, is an installer that contains your package(s) and can also contain your package(s)'s dependencies. It can then be distributed and when run it will install NIPM if necessary and then install your package(s) and dependencies. This is particularly useful when you want to distribute multiple packages together. The ability to build a package installer is currently available in LabVIEW NXG, but I expect it to be available in an upcoming version of LabVIEW (I don't want to make any commitments).

Another way would be to introduce a feature in NIPM itself to look for missing dependency packages in NI's online repositories if they cannot be found in an already connected feed. If you only had one package that depends only on NI dependencies (and the deployed machine is connected to the Internet), then I could see this providing significant value as you would only need to distribute the individual .nipkg file you built. However, not having your package(s) in a feed does have some drawbacks. If you wanted to make an update to your package(s) available, each machine that installed your package(s) would have to get an updated version of your package(s). I suppose you could use a hybrid approach where you put your package(s) in an internal feed which clients register and then get your NI dependencies at install time from the online NI repositories. This is something we will discuss further internally (again, not making any commitments).

Thanks.

Aaron Pena

Product Owner, Package Management

[Hooovahh]

---

@APena wrote:

One way is through a "package installer" which, as the name implies...

---

I have heard about this feature and the expected timeline and am excited to be able to use this.  Developing into a "thing", and then making a collection of these "things" is something we've been doing in LabVIEW for a while through several means.  Sure VIPM has VIPC (packages of packages) but from a higher level we've also done this through installers of installers (Inno Setup), and NI's Batch Installer.  All of these solve similar problems that a package installer will solve so thank you for this and I can't way to try it out.

---

@APena wrote:

If you only had one package that depends only on NI dependencies (and the deployed machine is connected to the Internet), then I could see this providing significant value as you would only need to distribute the individual .nipkg file you built. 

---

Another way to say this might be to make it "work like VIPM".  I have a single offline package that depends on OpenG.  I just double click my single package, and it finds OpenG packages.  Not because it is part of the same feed as my individual package, and not because they are both offline packages.  VIPM finds the dependent packages by looking at ALL feeds and finds the packages and versions which satisfies the need and installs it, then installs my package.  This is the user experience LabVIEW developers are going to expect from NIPM.  And this is the same user experience that we get from other package managers like OPKG for Linux RT controllers.  Just subscribe to feeds, install package(s) local or from a feed, find dependencies from all feeds, and install dependencies before the selected package.  All of this happens without the user needing to know where a dependent package comes from.

In my mind these two solutions are only loosely related.  Creating an installer with all dependencies bundled in is needed for deployment.  Installing a package on it's own and having dependencies internal or external can be for any number of reasons.  Is this a built application?  Is this source?  Is this neither and I'm just installing some glyphs for an icon editor?  The needs of installing a VI, or a PNG, vary greatly from the need to install an application.  But resolving dependencies is common between these two and it doesn't sound like NIPM currently handles it well from a users perspective.

[Gregory]

Hi APena,

I have sent GreyGrey a couple of my packages, and he has said that indeed no dependencies are listed. This happens when I automatically let it choose dependencies, or when I manually select the LV 2016 Runtime. I will post back here if there are any more developments.

Once again I am using the Package Build Support for LV 2016.

[Gregory]

It appears that the problem comes from building the package. The LV 2016 RTE is never listed as a dependency. I can add other dependencies on manually just for the heck of it, along with the LV 2016 RTE. The others do get listed as dependencies, but not the RTE.

[GreyGrey · Accepted solution]

Hi all,

We found that in order to get your dependencies to persist in your package, you must not use the auto-select dependencies option and instead must explicitly pick your dependencies from the build spec. Additionally, instead of hitting the 'Build' button from inside the build spec, if you click the 'OK' button, and then right-click the build spec from the project explorer and choose to build, the dependencies will persist. 

This issue has been documented and we will evaluate fixing this in a future version of LabVIEW. Thanks @gregoryj for working with me to get to the bottom of this!