VIPB draws in external dependencies - should leave them in their place

[Steen Schmidt]

Hi.

VI Package Builder (VIPB) has a defined Package Source (shown in the VIPB dialog). Anything called from outside this Package Source must be considered an external dependency.

VIPB pulls in external dependencies when it builds a package. For example, if my package is using a VI located at 'C:\Program Files (x86)\GPower\Shared\API Call.vi' then VIPB will copy 'API Call.vi' into the Package Source folder, relink to that, and then build the package.

This is a problem, since external dependencies should be left in their place. External dependencies are usually shared components with many users, sometimes even built to be installed at a specific location. Instead VIPB should do as it does with external dependencies in the LabVIEW installation folder: Leave them in their place. It's even worse when the external dependency is a PPL; In this case VIPB does not pull in the PPL, but it does do some relinking so the Package Source thinks the PPL has been relocated. That shouldn't happen either.

Comments, and acknowledgement that we need a fix for this?

Cheers,
Steen

[Jim Kring]

@Steen Schmidt I agree that this is something that needs a fix. I’m trying to think of there is ever a situation where it is desirable to have the current behavior. I can’t think of any off hand.

[Steen Schmidt]

On 5/26/2024 at 7:37 PM, Jim Kring said:

@Steen Schmidt I agree that this is something that needs a fix. I’m trying to think of there is ever a situation where it is desirable to have the current behavior. I can’t think of any off hand.

I can't think of any reason in this day and age either. Two decades ago the LabVIEW community was much less inclined to structured projects than today, so it would've been a help when a package manager/app builder sucked in that stray VI from your desktop. Then came the option in NI App Builder to leave PPLs alone instead of sucking them in. A similar option could be added to VIPB, to leave external dependencies in their place? This could preserve backwards compatibility, while enabling a shared component approach for those developers that work that way.

When the option is set to leave external components in their place, then VIPB could still work its magic to build MNU-files and project libraries to have valid paths to those external components once the package is installed.

Edited May 28 by Steen Schmidt

[Jim Kring]

@Steen Schmidt I agree with you about leaving dependencies in their place by default -- we actually do that. It's simply that "C:\Program Files" (and the '(x86)' variant) wasn't on the list of locations where external components were expected.  As always, things get a little tricky trying to support decades old paradigms.

Regarding a fix for this issue, can you try 2024.3.2761-rc2
here 👉 https://www.vipm.io/desktop/versions/

This should leave anything found under "C:\Program Files" or "C:\Program Files (x86)" along and not build it into the package.

[Steen Schmidt]

Thanks Jim, we're evaluating and will return here with our findings 👍

[Steen Schmidt]

One note of concern: Why are we stopping at excluding Program Files from being pulled into the package at build? External dependencies (that should be left in their place, and not be sucked into the package build) could lie everywhere. Other common places are Users paths, like for instance plugins to VS Code or other applications use. Or on an external volume, like many license managers do (plug in a dongle with your license files, which create a G:\MyLicense\product.lic for instance).

VIPB already lists a 'Package Source'. That should be the entirety of your source - everything, without exception, outside this Package Source should be considered an external component and be left alone by VIPB. Even if such a file is a mistake, an orphan left out there in the cold by a sloppy developer, it would not be a good help to pull it inside your source during build. It would on the contrary hide the problem from the developer and delay discovery of a package source problem.

Please give the developer control over the package source, instead of running opaque side effects during build.

Edited June 14 by Steen Schmidt