06-19-2019 02:13 PM
Hi,
We wish to have the user select which installed LabVIEW version a package should be installed under, when they install a package. NIPB lets us define a pre-install script, but that script doesn't allow us to change at the last minute which destination to install to.
Use case is for instance an add-on to LabVIEW, which must end up in C:\Program Files (x86)\National Instruments\LabVIEW 201x\<something>\. User might have installed both LabVIEW 2018 and 2019, so user must select at install time which LabVIEW version the package should install to. How?
We also need that same package be installed both at C:\Program Files (x86)\National Instruments\LabVIEW 2018\<something>\ and C:\Program Files (x86)\National Instruments\LabVIEW 2019\<something>\ for instance at the same time (one installed after the other), and have those two install sessions be uninstalled independently of each other. How?
Both are breaking requirements for a package management tool for us.
06-21-2019 10:39 AM
One way to achieve this is to have different packages that would provide support for each version of LabVIEW. Those packages would list their supported version of LabVIEW as a dependency. Then, you would have a top level package that would recommend each of the support packages we created, and only the ones that have their corresponding version of LabVIEW installed would show up for selection (or deselection) by the user in the installer.
This is how many of our products architect their packages. For instance, the different SystemLink API support for LabVIEW versions is done this way.
06-22-2019 11:24 AM
Sure, but that would severely complicate our build process when updating a package.
We manage perhaps 100 different re-use packages. Each time there is an update, even minor or bugfix, when we build the package we have to build it maybe 6 or 7 times on different VMs with each of the LabVIEW versions we want that package be usable on. When a new LabVIEW version is released, we must then go back and rebuild every hitherto released package for that new LabVIEW version. That’s tens of thousands of packages to manage, and perhaps 3000 packages to rebuild when a new LabVIEW version comes by.
Effectively it would mean that LabVIEW is no longer source compatible from version to version, since we need to build a specific package for each version anyway. Because we can’t dynamically select a destination path from the package installer?
Doesn’t sound like a good solution to me. But would of cause solve the ability for side-by-side installations of the same package for multiple LabVIEW versions (which is not currently possible with NIPM either).
06-24-2019 04:49 AM - edited 06-24-2019 04:52 AM
SteenSchmidt,
We had the same kind of frustration when first tried applying NIIPM to our products. We are convinced that this is the right approach, but it can only be successful if your company invest in DevOps / build infrastructure, so you will be able to manage a lot of packages and their dependencies.
One of the core features of NIPM (as I see it) is the support of unattended installations and the massive use of CLI tools / scripts to automate your installation process. There is no room for user dialogs in this philosophy. You have to have many packages, if you want to support different LabVIEW versions. This can even bring you some benefits (for example, you can remove block diagrams to protect your IP).
If you have a set of packages of a single product, you can build your very own installer and use CLI to give the User ability to select the package they want to install. Or you can follow the suggestions from Brandon Grey and define "suggests" relationship, thus delegating the selection feature to the native NIPM GUI.
As for now, we see VIPM, MGI gpm and InnoSetup installer as an alternative. We ended up using all of them 🙂
06-24-2019 05:05 AM
We can't remove block diagrams anyway, due to problems with .vim in that case. Also Conditinal Disable structures seems finicky about block diagram removal, so after a dev has spent weeks investigating it was a thumbs down on BD removal for the time being.
A packaging solution that can only be succesful if you invest in DevOps / build infrastructure... Ok, I see a problem with that in the general sense, for instance that that will never fly with the single users or organisations that don't have hours to spare or dollars to burn. Like for instance our company.
We will return to VIPM then and think no more of NIPM. The difference seems to be that the creators of VIPM actually understands the challenges facing LabVIEW users, we're not just deploying "an app", we're actually managing a highly complex web of interdependencies. No NIPM also puts an effective stop to us using (and re-selling) SystemLink though, which we are in the middle of really integrating for both TestStand and real time managed assets.
06-25-2019 03:18 PM
Hi SteenSchmidt,
As Brandon mentioned in his earlier post, the current way to support multiple versions of a product (LabVIEW, in this case) is to have a separate package per version of the product.
That being said, we do understand that for some this may be an inconvenience and we do recognize the value that products like VIPM and GPM provide with their tight integration with LabVIEW, specifically. Figuring out how we should facilitate these use cases while still maintaining a platform approach to our packaging technologies is in our backlog and actively being discussed.
As an input to those discussions, I would be very interested in learning more about your specific use case and how you currently manage your re-use packages. If you are interested, let me know and I can set something up.
Thanks.
Aaron Peña
Product Owner, Package and License Management