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).
Post your ideas that are related to NI package management. This includes NI Package Manager, NI Package Builder, creating NI packages (.nipkg), distributing NI packages (.nipkg), managing feeds, and more.
