Why LabVIEW Package Builder cannot be used for distributing .lvlibp?

[NikitaProrekhin]

Hi,

Is there any special reason for not allowing including .lvlibp files to a LabVIEW package?

From LabVIEW Package Builder help file:

Spoiler

In LabVIEW, right-click Build Specifications and create an application, source distribution, or DLL. 

I know that there is a possibility to create a package that includes an application and .lvlibps that are referenced by this application. But why I can't create a package that contains only .lvlibp files?

Thanks,

Nikita.

[billko]

---

@NikitaProrekhin wrote:

Hi,

Is there any special reason for not allowing including .lvlibp files to a LabVIEW package?

From LabVIEW Package Builder help file:

Spoiler

In LabVIEW, right-click Build Specifications and create an application, source distribution, or DLL. 

I know that there is a possibility to create a package that includes an application and .lvlibps that are referenced by this application. But why I can't create a package that contains only .lvlibp files?

Thanks,

Nikita.

---

Isn't a packed library already a package?

[JoshuaP · Accepted solution]

Is there any special reason for not allowing including .lvlibp files to a LabVIEW package?

You can't currently add a PPL to a package using the LabVIEW Package Builder Addon.  We will add support for them in its next update, which should be posted in the next 4 weeks or so.

[JoshuaP · Accepted solution]

You can't currently add a PPL to a package using the LabVIEW Package Builder Addon.  We will add support for them in its next update, which should be posted in the next 4 weeks or so.

[NikitaProrekhin]

JoshuaP and Bill

Thanks for the answers.

Indeed ppl at some point is a package of distributable functions, I agree. But I think a Package in terms of LabVIEW Package Builder and NI Package Manager is bigger than just a file you can give someone  

My primary goal is to try using NI Package Manager for distributing different ppls (plugins) and compiled apps to an end user. What I like about using a package manager in general is that it allows you to search for a package, to read its description, to check dependencies and to deliver updates.

My understanding of existing package managers for NI products is the following:

1. VIPM is for delivering add-ons and libraries to LabVIEW developers

2. NIPM is for delivering and installing binaries, drivers, compiled libraries etc. to users. It is not tied to LabVIEW only, it is a general package manager around NI world.

JoshuaP: Is my understanding of NIPM capabilities correct? Is it possible to automate building Packages using LabVIEW (like setting package version, modifying description programmatically etc)? Is there a manual or a guide for creating manifest files and setting up your own NIPM feed?

Thanks,

Nikita.

[dzakich]

Joshua, I have a similar question  - will NI Package Manager be replacing JKI's VIPM by offering similar functionality for distribution of shared development codebase (that is targeting software developers and development package distribution) or NI Package Manager will be a complimentary utility for managing and distribution of packages primarily geared towards end-user deployment?

I've given NIPM a spin and found it to be very limiting (with respect to VIPM) in the following categories:

* Build specification of target location of package deployment is limited to Program Data/Files, Desktop, User Home, etc. This is a big giveaway that NIPM is focused on application distribution to end-users.

* Limitations imposed on source files format. (Sidestory: Actually, NIPM was unable to detect any files with .vi extension under Source Files. As a test, I was trying to build a package with instrument driver (project style). My project definition contained .lvlib file with its memeber VIs. However, while trying to create a build spec for a package, NIPM failed to detect any source files present in a project. It only detected a bunch of .mnu files.)

*No option to mass-compile for different versions of LabVIEW (similar to VIPM) using only a single package file. Also, semantic versioning forces another package container to be created and is not inherently contained within a container. This leads to accumulation of package containers each having an iterative revision. 

My company is using VIPM for management and control of shared reuse libraries amongst developers (and we are not the only ones). This makes me very curious about NIPM identity and its role in NI ecosystem. So far I can only see NIPM + VIPM coexistence - is this the true story?

In advance, I'd like to thank everyone for comments and replies.

Kindly,

Stas

[JoshuaP]

The 17.0.1 upgrade of Package Builder should be available in the NI Package Manager, and should enable you to create packages with package project libraries.

NIPM is not trying to replace VIPM for the current versions of LV and they can certainly co-exist.  The goal was to have a first class package manager for NXG and enable customers to create packages and declare dependencies on NI software.  In the future you should be able to completely replicate a test system using NIPM.  That is something VIPM could never do for the current versions of LabVIEW.

We intentionally hide VIs from the source menu since it can be very problematic to include them directly in a package.  If you need to distribute VIs, we highly recommend you create a source distribution to fix up any path issues and then include the source distribution in your package.

[dzakich]

Thank you very much answering my question, Joshua. I can certainly see the huge benefit of NIPM in production environment where test asset replication must be done fast and often and production rates increase. It appears that VIPM and NIPM are rulers of their own application domain and must be used side-by-side:

VIPM being developer-centric (especially in multi-developer organization where common codebase and reuse are essential), and

NIPM being customer-centric (where customer can be as generic as a test station where application test set muse be deployed).

Joshua, do you know if internally LabVIEW R&D is using VIPM for managing of shared development code? 

Kindly,

Stas

[NikitaProrekhin]

Hi Joshua,

Thanks for the update! I can't see 17.0.1 package available in NIPM, I guess it will be live soon.

Am I right saying that NIPM will become a replacement for traditional MSI installers that are used for distributing compiled LabVIEW applications to end customers? Is NIPM idea similar to Chocolatey or Windows Store? If yes, this would be very very good I think. 

Nikita.

[JoshuaP]

It looks like I spoke too soon.  We have updated the Package Builder in the backend, but it doesn't seem to be live just yet.

Yes, NIPM will replace traditional MSI installers for NI products similar to Chocolatey or the Windows Store with some additional enhancements like advanced dependency management.

[JoshuaP]

The new version of LabVIEW Package Builder is now in the store.  You should see an upgrade if you when you launch NIPM if you already had it installed.