Install the same package to multiple versions of LabVIEW

[Chris_Cilino]

We desperately need the ability to install the same package to multiple versions of LabVIEW. Specifically, we need support for symbolic paths as a destination (user.lib, vi.lib, instr.lib, etc). 

Basically duplicate the VI Package Manager's ability to install a package to multiple versions of LabVIEW. I think the VI Package Manager work flow should be duplicated as well.

FYI: 

https://labviewwiki.org/wiki/Package_Manager_Comparison

[CL_eisenwr]

Chris,

You may want to look into NI Package Builder (NIPB). NIPB does support more pre/post install/uninstall actions. It also has GUI and command line interface.

[APena]

Hey Chris,

I'd like to take a step back and ask a clarifying question to make sure I'm really understanding the problem we're trying to solve:

1. Is it really that you want to be able to install the same package to multiple versions of LabVIEW? Or is it that the contents of a package (presumably some reusable piece of code) should be usable/accessible in more than one version of LabVIEW without modification?

More specifically,

1. Is it that as a package author you don't want to have to rebuild or otherwise modify your package when a new version of LabVIEW is released?
2. Is it that as a package consumer you don't want to have to wait for the author of a package to rebuild or otherwise modify their package when a new version of LabVIEW is released so that you can use it in the new version of LabVIEW?

Thanks.

Aaron Peña

Product Owner, Package and License Management

National Instruments

[Chris_Cilino]

Hey Aaron

For sure. I think we have to define what "install" means.

When I say install I mean "all actions necessary to provide functionality and UI UX around a body of software". So that clearly entails the files that do the work like apis and such. But it also means palettes, wizards, and other IDE specifics such as install locations to vi.lib, user.lib, instr.lib and mass compiling, etc.

I would like to be able to have the same package provide the same user experience regardless of the version of LabVIEW they are using the software in. 

As the builder, I would like to build one package that accomplishes the installation as defined above. One of the most important reasons to have one package do the installation is to prevent confusion over what version of a package is installed.

As a user I don't want to have to grab the right package depending on my version of LabVIEW. Think of this as the NI-DAQmx model. I get DAQmx 19 and that installs "support" for LabVIEW 32 and 64 bit, 16, 17, 18 and 19. One "thing" does all that is necessary to provide the same user experience across the versions of LabVIEW found. 

And as a user, you're right... I don't want to wait for a new version of a package that provides support for a new version of LabVIEW. That would be dreadful and put a heavy burden on the developer of code. 

Hope that helps.

[Chris_Cilino]

One slight amendment... I'd hope for the option to select one or multiple or all versions of LabVIEW found on the system. In other words, an installation doesn't force itself on all installed versions.

[APena]

That's very helpful. Thanks, Chris.

 - Aaron

[Hooovahh]

@APena - I'd say both are important.  As a developer (creating the package) I find it extremely limiting to have a package only be made for a single version of NXG, meaning I have a support nightmare.  If I have 20 packages out on the community, that means I need to make another 20 every time a new version of NXG comes out.  And if I change careers, all 20 of those packages are now not usable in the next version of NXG.

As a developer (consuming the package), I don't think having one package install support to all versions of NXG installed is the right solution either.  GPM is an open source package manager for LabVIEW that installs reuse on a per project bases.  MGI made this because they were working on multiple projects in the same version of LabVIEW, and needed a way to use version 1.0 of a package in one project, and version 2.0 on another project.  Using VIPM this would mean having to apply a package configuration before switching projects.  I think having a system that installs version 1.0 of a package in all versions of NXG is even more restrictive than the current VIPM solution, which at least allows for different versions of a package to be installed in different versions of LabVIEW.

I first heard of NIPM in 2014 and since then I've been saying "Make it work like VIPM".  Not because it is perfect but because it is what other LabVIEW developers are familiar with.  Major paradigm shifts in package management can be a reason to not migrate reuse, which means less community tools, which mean less adoption.

[MaximeR]

Hi,

i love the idea. Like we have in VIPM we can use package to distribute code that can be use in development. In this case, we can develop code in selected version of labview and be able to support new version without rebuilding a specific package. We can have multiple version of LabVIEW of course.

I want to add this for TestStand too with NIPB. If we build a package to add some steptypes to TestStand, for the moment we need to build a pakage for each version of TestStand. It's a little bit frustating, because if your step types are based on LabVIEW,  since LV 2017, we can build lvlibp that can be run with newer version of the run time. So you didi the job for the compatibility but not for the installer.

TestStand is a little bit different, because you can have only one version active at a time on your computer. But the issue is that the package builder is evaluating the path to deploy at build not at deployment. For example, TestStandpublic folder have a envrionnement variable. When you build you can select to deploy to TestStandPublic folder. But in fact, it evaluates the path at build not at installation. It's not a good approach for me because user may have change the TestStandPublic variable, and in this case it will not work at all.

It's not exactly the same issue than this one, but it's link. We have a forum on that subject https://forums.ni.com/t5/NI-Package-Manager-NIPM/NI-Package-Builder-How-to-specify-to-evaluate-TestS... 

Best regards.