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).