NI Package Management Idea Exchange

Top Authors

User

Kudos

Post an idea

Hello

In addition to the idea mentioned in the following post,

https://forums.ni.com/t5/Additional-NI-Software-Idea/NIPM-queued-amp-scheduled-download-amp-install/idc-p/3963380#M541

would like to propose that the NI offline package to be installed entirely in offline mode, rather than trying to connect and fail, whenever a connection seemed present.

and on top of that, offline installers to be able to be integrated into a local repository in our own network, and packaged distributions can be directed to them, as not all operation PCs are given access to the internet. For the time being, let the browsers handle auto-resuming downloads.

View All (1)

The NIPKG format allows dependencies to be listed by package name, and of particular interest, groups of packages to satisfy a dependency - that is, a dependency can be satisfied by any one of a collection of packages (see the "|" character at http://www.ni.com/documentation/en/ni-package-manager/latest/manual/control-file-attributes/).

Meanwhile, many packages are available in more than one format - e.g. NIPKG, VIPackage, GPM package.

However, if I install package A with VIPM, and package B depends on it, but I try to use NIPM, I'll see I have a "missing" dependency.

Worse, if I now install 'package A' with NIPM, (assuming the packages are equivalent) both systems will believe I have the package installed, but uninstalling from either won't affect the other (leading to broken code).

Could NIPM gain the ability to allow specifying dependencies on non-nipkg packages?

This could be either via specific other package managers that could be checked (VIPM, GPM?) or perhaps via some "pre-install dependency scanner" VI.

In the former case, perhaps I could list "PackageA|VIPM::PackageA" as the dependency.

In the latter case, I as the developer of B could write a VI which checks some details (e.g. existence of specific VIs on disk, or call into VIPM/GPM, etc), and then output a boolean indicating if I (the package B developer) believed my dependency on "PackageA|VIPM::PackageA" (by package name) was satisfied. (In this case, I'd probably just give the dependency as "PackageA" though...)

I think this would be useful especially when sharing code more widely.

I don't expect that this idea would cover searching for packages in other managers' repositories though - if it fails whatever "is currently installed?" test, and can't be sourced from NIPKG feeds, then the install should give the current dialog (missing PackageA).

View All (1)

Blacklisting packages

I'd like a way of "blacklisting" an NIPM package, even if it's in a feed and selected for install For example, I could register the feed for the package "ni-labview-2020-core-x86-en" and also want to install all of the recommended packages (using the --include-recommended flag), except for one. Let's say for some reason I don't want Report Gen Toolkit, for example.

The only option I can currently come up with is installing LabVIEW 2020 without any of it's recommended packages, then installing all of the recommended packages separately, except omitting RGTK. It would be really great if there was a command to simply prevent RGTK from ever installing, even when using the "--include-recommended" argument.

In terms of use cases, let's say an administrator wants to give their users some freedom, but never wants a particular package installed (or upgraded past a certain point) for some reason. This would be similar to the dpkg or apt functionality described here (https://www.linuxuprising.com/2018/10/how-to-keep-package-from-updating-in.html) or (I think) the okpg "flag" operation described here (https://openwrt.org/docs/guide-user/additional-software/opkg).

Keep valid license when updating.

Our IT department has now opened up using NI Package Manager to install LabVIEW, and is leaving it to us to do these installs, reducing their role largely to managing licensing. This even includes installing the IDE for our coders.

I can't complain that they've opened this up, except that there are a lot of choices to make, not just in what main elements to install, but in option selections in prompts presented by the installers. it would be nice if we could have NIPM build up a script of all the elements we're installing (IDE, extras, drivers) and all the selections we make during this process. It should then save the script when the NIPM session ends, and allow appending an existing script should a script be built up over multiple NIPM sessions that might be interrupted by a restart required by one of the installs.

Ideally these scripts, when run, would either bypass the restarts normally requested after some installs until the end of the complete process, or would auto-continue after restarts that couldn't be skipped. Also important would be having it gather together all license/agreement requirements into a single prompt at the start of the script so that they can all be accepted at the start of the process rather than being prompted as each element install starts, or, better yet, have the script do a "silent" install with all licensing considered to be accepted and no prompts appearing.

Additionally, these scripts should then be editable so that if users discover they need additional drivers or libraries, different versions, or don't need some elements, they can be added to, revised, or removed from the script. It would also be great if we could make scripts that included uninstallations in the script, so scripts to upgrade from one revision to another could be built.

My vision for these scripts is a simple collection of scripts that would let us quickly get any user or test system up and running with everything needed, whether it's a new employee or an existing user or system getting a computer refresh, with minimal hand-holding of the process and no (or minimal) mistakes. My thinking is we could have a small handful of installer scripts that would fit the needs of 90%+ of our different systems that all use LabVIEW, leaving one-off systems to need only a few NIPM runs to complete their setups.

Thanks,

Erik

View All (2)

About the software install path

This probably applies more to building a NI Package via Application Builder, but would be helpful if you could do it with NI Package Builder (NIPB). It should be easier to call a VI(s) as a custom execute steps of a package. You can do this currently by making your VI follow the LabVIEW CLI pattern. However this does requiring a lot of manual entry from the user to do in NIPB, thus being error prone. Also to do with the Application Builder, you have to make a batch file and add that to project even thought the batch fill does not need to exist other than to do the install/uninstall.

View All (3)

there must be a better way to uninstall NIPM without having to uninstall all NI software as a prerequisite, at least that I hope there is

knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJ6oSAE&l=en-US

do consider allowing NIPM to be uninstalled independently, as I believe most of the pre-NIPM era users have and still require those 8.5-201x LabVIEWs (for maintenance and backward compatibility with legacy hardware) that were already installed properly (with kinks ironed out). NIPM to rebuild the feedlist based on pre-NIPM-install NI software products, maybe?

recent installation of SPB2019 from an offline installer package (due to poor connection) in my new machine has included a malfunctioned LM (constantly fail to connect server), and solution provided was to remove and reinstall the LM. Upon the initiation of the removal, NIPM removed all installed license-able (but yet to be activated software) software from my machine... with no possible way to stop the process... the HORROR on my face is no less than this guy here =>

can I suggest LM removal to remove the LM and activated licenses only; rather than all the other un-selected, but license-able software?

I had a issue on Windows 11 where the NI-MAX configuration got corrupted. An NI Technical Support Engineer advised me to set the NI Device Loader service to 'Delayed Start' and change the 'Recovery' tab to 'Restart the service'. That solved this issue.

But the problem is that using NI Packet Manager to repair or install things, this NI Device Loader service is sometimes reset to ‘Automatic’ and then also the ‘Recovery’ tab is back to the default values. So we must check those settings every time after using the NI Packet Manager.

Idea: If a service is already there, NI Packet Manager should not change the properties of that service.

If a package fails to install, there is never anything helpful presented to try to diagnose the problem.

image (8).png

This is hot garbage.

I end up having to run nipkg.exe from command line to get some modicum of feedback, but even then it's usually still insufficient.

My latest use case is that I have created a pre-install.bat file (configured to run as a pre-install custom execute, per my package build spec), and that bat file is intended to throw an error (set nonzero return code and route message to stderr) if some required dependencies do not exist. I went to the trouble of doing these sanity checks and building meaningful errors, but they don't actually get exposed when I run the installer, so I'm left guessing as to what went wrong.

When installing NI software with NIPM, it would be useful for NIPM to be able to connect to VLA server and determine avalable software to install based on the available licenses.

Example:

A user wants to install NI software and contacts the VLA administrator.
The VLA administrator assigns software rights to the user/computer and instructs the user to download and install NIPM and connect to VLA server
The user installs NIPM and is given an option to select software based on the VLA

This could be used instead of a "Volume license installer" avaliable in VLM.

Best regards

Matej Zorko

View All (2)

I'd like to be able to select a collection of nipkg files in e.g. Windows Explorer and use NIPM to install them in the correct order based on their interdependencies.

If I create a local feed and add that, then NIPM will allow this via selection in the Packages tab.

However, there doesn't seem to be a method to select multiple files that are not in a feed using a GUI (Windows Explorer or NIPM etc).

VIPM has an "Open Package File(s)" menu item that fills this role.

I think (although I didn't test, because I didn't consider this when I was running into this issue) that using "nipkg.exe install A.nipkg B.nipkg C.nipkg" would work for this, so there is a workaround. I just didn't consider it earlier...

NI Package Management Idea Exchange