Add possible dependencies on non-nipkg packages

[cbutcher]

The NIPKG format allows dependencies to be listed by package name, and of particular interest, groups of packages to satisfy a dependency - that is, a dependency can be satisfied by any one of a collection of packages (see the "|" character at http://www.ni.com/documentation/en/ni-package-manager/latest/manual/control-file-attributes/).

Meanwhile, many packages are available in more than one format - e.g. NIPKG, VIPackage, GPM package.

However, if I install package A with VIPM, and package B depends on it, but I try to use NIPM, I'll see I have a "missing" dependency.

Worse, if I now install 'package A' with NIPM, (assuming the packages are equivalent) both systems will believe I have the package installed, but uninstalling from either won't affect the other (leading to broken code).

Could NIPM gain the ability to allow specifying dependencies on non-nipkg packages?

This could be either via specific other package managers that could be checked (VIPM, GPM?) or perhaps via some "pre-install dependency scanner" VI.

In the former case, perhaps I could list "PackageA|VIPM::PackageA" as the dependency.

In the latter case, I as the developer of B could write a VI which checks some details (e.g. existence of specific VIs on disk, or call into VIPM/GPM, etc), and then output a boolean indicating if I (the package B developer) believed my dependency on "PackageA|VIPM::PackageA" (by package name) was satisfied. (In this case, I'd probably just give the dependency as "PackageA" though...)

I think this would be useful especially when sharing code more widely.

I don't expect that this idea would cover searching for packages in other managers' repositories though - if it fails whatever "is currently installed?" test, and can't be sourced from NIPKG feeds, then the install should give the current dialog (missing PackageA).

[Chris_Cilino]

I love the idea of inter-package manager dependency. As I've shared in GCentral's presentations (see timestamp 23:10) having three package managers fractures our precious community code in three ecosystems and reduces a community member's efficiency in finding, using, and distributing code. I would love to see these fractures healed. And, to be clear, GCentral does not advocate for one package manager above any other. Rather GCentral is seeking to improve the collaborative experience of our community so that we can all get our jobs done quicker. I wholly support any efforts by the package manager owners (NI, JKI, MGI) to enable inter package manager dependencies. 

In the GCentral survey, community members are answering the last "general thoughts" question with their discomfort in having three package managers. And to be clear, GCentral is not attempting to solve the problems caused by having three package managers directly. But it seems like the community has no other outlet. Here are some of the comments:

• my wish is to have one tool that can access all the sources, I think VIPM is this tool. currently I only use packages I can install with VIPM some of the community packages I use are not published on LVTN so I have to keep track of their evolution and make them easily available to my team : this is a pain.
• There should be one tool not 3.
• Main issue for me in reusing code is that if I can only find a VIPM package of it, but I prefer GPM and having all my code in the same folder as my project...