Allow Packed Project Libraries to serve as a valid <foundvi> path for "missing" subVIs

[crandiba]

With increasing support for PPLs it would be great to have them be a valid <foundvi> location.

It becomes most evident when refactoring a .lvlib into a .lvlibp.

In cases where we replace "LibraryX.lvlib" with its compiled version of "LibraryX.lvlibp", we easily end up with some VIs that referenced subVIs from the original LibraryX.lvlib that need now to be updated to refer to the versions in the .lvlibp instead.

However, even after manually locating (and selecting) the first "missing" VI from inside the LibraryX.lvlibp , it does not behave as a "conventional" folder would: listed in the default search paths under the <foundvi> category and saving us the trouble of selecting every other "missing" subVI from LibraryX.

To be fair, the workaround exists in having the original LibraryX.lvlib present and replacing it with the PPL version for all projects that use it, but it strikes me as one that could be avoided.

Please let me know if that made sense and I'll do my best to clarify it,

Thanks all,

Cris

[AristosQueue (NI)]

*sigh* I am sorry. You are yet another user bit by the "p". That extra "p" really hoses a lot of systems. It's the worst architectural decision I know of in LabVIEW, one we are *not* repeating in LV NXG!

I'd like to hear the community feedback about this idea. I have some concerns, which I'll spell out below, but PPLs are one area where I think we could trade away safety for power, and if a change like this makes them more usable, maybe we should make that trade.

You mentioned the workaround... LV 2019 improved significantly the "Replace With..." menu option to help you do the swap of the .lvlib for the .lvlibp. Take a look and let us know if it helps with your situation.

Here's the potential pitfalls I'd worry about:

Allowing the PPL to be part of the search path is potentially dangerous. 1) Suppose you've started loading a VI that is a member of a .lvlib. It cannot find its .lvlib, but it finds the .lvlibp. But the VI is already in memory. I'm not sure how that is supposed to work -- we'd need to forcibly unload the VI before starting to load the .lvlibp?  2) It could lead to unintentional crosslinking in some scenarios: particularly common where source model for callers of the original .lvlib (test harness, commonly) gets crosslinked against the PPL because the source searched for a missing dependency. (Worse: some users have code that talks to both the .lvlib and .lvlibp simultaneously to verify same behavior before and after build.) 3) Swapping the .lvlib for .lvlibp also breaks the unflattening of flattened LV classes stored inside VIs (i.e. default control values and constant values).

It's a mess.

[crandiba]

Hi AQ,

As always, thanks a lot for the input;

Yes, I was quite happy to see the new feature from LV 2019, maybe the one I appreciated the most. However, it doesn't do much for us in this case, where we have an .lvlib that is referenced in many projects that we would like to replace by the PPL - still need to go in every project (or load as much as we can into memory) and locate the "missing" VIs manually.

As for your points:

1) I would say that the PPL itself would not allow the VI to be brought into (under?) the PPLs namespace. 

2) Perfectly fair point, but I think we can also encounter similar crosslinking/loading-the-unintended-VI issues with the system we have now

Thanks again,

Cris