Need a Way to Reverse-Replace Packed Project Library with LabVIEW Library

[Pie56694]

This idea is about a new LabVIEW feature, the Packed Project Library.

To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.

But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.

If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.

What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.

My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).

This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.

Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.

Thanks!

Steve

[GregSands]

I haven't used packed libraries, so I might be quite off-track, but would it also be necessary for the namespace of VIs in a library not to include the .lvlib/.lvlibp extension?  i.e. Utils:Solve.vi rather than Utils.lvlibp:Solve.vi

[Pie56694]

Your comment makes me wonder what happens when two differently named packed libraries contain a like-named VI and you want to use them both in the same project.  I think the lvbitp should act as a logical directory and one VI would be in conflict.

Here's some recent feedback from the developer, "I recommend having two projects: one project where you make changes to your source code and libraries, and another project where you use or test your packed library."

[PaulLotz]

We encountered the same sort of issues you describe.  I think it is will be essential to implement this idea before packed project libraries become useful.  (For now we have abandoned packed project libraries entirely.)

[littlesphaeroid]

As of LV2014 is appears to be imposisble to do a find and replace of PPL dependencies. So once you've replaced VIs froma lvlib with a lvlibp, you're stuck with those in that project without manually updating all call instances of the VIs in the PPL. Wow. 

[Darren]

Available in LabVIEW 2019 and later. You can right-click a .lvlibp in the project and select 'Replace With...' to replace it with an .lvlib, and vice-versa.