Provide ability to create "Online installers" through nipkg / NIPB / LabVIEW

[jyoung8711]

When I go to download a new piece of NI software, there is an online installer which:

1) Installs the latest version of NIPM

2) Registers any needed feeds

3) Presents an installer dialog to user

4) Installs product

5) exits gracefully.

And is <10 KB in size.

It would be incredibly useful to be able to create such an installer through on of the available builder interfaces that points to (for instance) network feeds, or a partner feed, or something like that.

There are currently some "work arounds" but they all are rather complex, clunky, and require a level of BAT file execution that's not really easy.

(I could probably do this easier through LV coding, but if the LVRuntime isn't installed, that doesn't really help me :-))

[JoGra]

I highly second this idea!

We have the options to build installers in the labview package build definition and the ni package builder.

This idea would just need an option to exclude all depended packages which can be downloaded through the ni feeds. 

The resulting installer should then only container:
- NI package manager

- User packages

[Scott_Richardson]

Adding lower-level control to LabVIEW and NI Package Builder might be a lot of work to properly expose with all the permutations that you might require for you specific needs.

If you are interested in this idea, would the need to expose this in LabVIEW or NI Package Builder be mitigated by the availability of a simple installer-builder console tool that takes as input a config file that contains the list of top-level packages the installer will install, what URI to use when installing, and what dependencies to include or not include in the installer's pool?

[JoGra]

Hi Scott, 

Thanks for your answer!

Yes, detailed lower-level control would add complexity to the existing tools and a commandline interface (prefered anyways for automated builds) would be a good option.

However, the option to build an "online" installer instead of the current offline installer should not need any configuration more than an "online installer" check box which would cause the installer build process to skip including all of the dependency packages from the ni feeds into the build installer. The depencies are still defined in the user package and when it gets installed they will also be downloaded and installed. This would result in a much smaller file size and give the installer a modern purpose as many machines are connected to internet anyways.

Or should I create a new idea for this?

---

[jyoung8711]

Scott --

What you describe would work well for my use cases.  In the absence of such a feature we have gone ahead and created something like this ourselves out of some batch scripts and the 7za tool.  It will automatically download and install a NIPM installer (from a configured location) and then register some number of feeds, and trigger a package to install for each of those feeds. I wouldn't be surprised if something similar happened to the NI "Online Installer" options as well.

One of the challenges we've still run into is the digital signing of this installer as well as some error handling for various conditions. We could continue to evolve our current solution but I would personally much rather see something like this supported by NI for the long term.

@JoGra -- The original idea post would require more than just a "online installer" option.  It would need to know where feed(s) / package(s) and NIPM installer(s) are located.  In many cases this changes depending on whether we're looking at NI feeds, our company feeds, or internal local feeds (for customers that have firewall challenges).

[Scott_Richardson]

Thanks for the responses.

I think the request for online installer support for LabVIEW could gather more external support if posted directly to the LabVIEW idea exchange. I currently do not see such an idea. I agree that a single option could potentially satisfy the simple workflow to only install NI software packages from ni.com, but LabVIEW would have to consider how to handle the other permutations where NI packages are hosted on non-ni.com feed locations (intranet and/or network drives).

NI Package Builder already has more flexibility, so a single option would likely not be enough, so that is why I am researching the idea of a lower-level tool.

NI installers behave just like you suggested: install NIPM, register feeds, install software, and if offline installer unregister feeds.