Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
NI Package Management Idea Exchange
Post your ideas that are related to NI package management. This includes NI Package Manager, NI Package Builder, creating NI packages (.nipkg), distributing NI packages (.nipkg), managing feeds, and more.
I've been informed by NI support that current versions of LabVIEW can only be installed silently by installing Package Manager first and then using batch scripts for installation. Previous versions of labview supported silent installation using typical msiexec flags. The current tool, INSTALL.EXE only supports a passive switch which requires an interactive gui for it to successfully run an installer with application options other that the Package Manager. This is far from an ideal situation for mass deployment to computer labs and it ends up causing a waste of time and effort. Please add silent installation options to install.exe and add the ability for INSTALL.EXE to show installation parameters when it is passed some sort of common help parameter (such as --help, -h, -? ).
If you haven't seen it, GPackage (https://gpackage.io) manager is a new package manager that has a tremendous amount of promise. It offers the ability to install different versions of the same package simultaneously to a version of LabVIEW. This allows the creation of "sandboxes" where on a per project basis I can tightly control which version of software I'm using. Another way of saying it, I can prevent the upgrading one version of a library from having unintended effects across different projects.
I would love to see NI package manager \ LabVIEW support a per project "virtual environment". I could see this being accomplished by creating a per project user.lib and instr.lib. But that's just one idea...
I highly recommend NI examine, in detail, G Package manager and incorporate its per project capabilities into LabVIEW and NI Package manager. The ability to install multiple versions of the same package on a per project basis solves quite a few problems. That having been said we would also need the ability to install one package globally and resolve conflicts between the per project and global versions of a library.
FYI: please be aware of the labviewwiki.org article comparing the three different package managers:
We should be able to filter the Packages displayed by Feed. This would allow users to focus on their internal feeds and find packages quicker. Particularly when basic LabVIEW\TestStand shows 90+ packages (300+ with hidden shown), the drowns out the internal packages. This would allow for more categorization than the Maintainer and limited Categories (improvement idea) afford us currently.
Allow uninstall packages where pre/post uninstall actions fail. Right now, if the package has been created with an error in the pre / post uninstall action, then the package can't be uninstalled - the user is stuck with this package and can't even upgrade it.
I propose to allow adding dependencies in NI Package Builder that is not part of the active solution - and that are not NI packages. It should be possible to press "add dependency" and then type in the package name as free text
It would be helpful to be able to define additional Categories/Sections for NI Packages. This would help users quickly narrow down searches to find packages. This is needed since there is not a way to filter the packages by feed in NI Package Manager.
What: installing a package on a newly installed machine where only NIPM has been installed. Dependencies to e.g. DAQmx Runtime and Labview Runtime
The problem: the installation will fail as NI Package Manager does not know the feed locations for the dependent packages. If these packages had been installed previous and uninstalled, then the feeds would be known and the installation could pass.
Proposed solution: Whenever a package requires NI products as dependencies, the Package Manager should automatically search / add the feeds from NI.com and install them
How nice it would be if my NIPM feed could point to GitHub-hosted packages! This way, I don't need to maintain my own file server. I created a custom feed to try it out; this is what my Packages.gz contains:
Description: Provides support for the NI Scan Engine and EtherCAT custom device for NI VeriStand 2018.
DisplayName: NI Scan Engine and EtherCAT for VeriStand 2018
Maintainer: National Instruments <firstname.lastname@example.org>
Alas, although NIPM accepted the feed, it did not allow the package to be downloaded ("Redirection to another URL is forbidden"):
It turns out that the nice URL above actually redirects to an Amazon cloud storage location, and the final URL is like
Could the restriction on redirections be lifted somehow? Perhaps there could be an optional property in the feed to specify that a particular Filename is allowed to redirect elsewhere. Perhaps the feed creator can nominate one or more "whitelisted" domains for a particular Filename's redirection.
It would be nice if the IDNet instrument drivers NI host for LabVIEW 20xx were available as NI Packages. Currently only LabVIEW NXG instrument drivers are available as NI Packages. Also it would be nice if they were available to be searched from within NIPM.
the package manager seemed like cannot even populate nor remove installed packages without internet connection. is it a bug? as mentioned from the other ideas posted previously, not all operation computers are granted internet access. please look into it. thanks
just a suggestion, installer packages should be given the option to able to be installed/removed by itself, with the PM being a complementing tool, especially for inter-version compatibility during this transition period.
When adding a Package Installer, NI Package Builder is currently limited to only configuring the options on the top level, first page of a suited installer (i.e. "NI-IMAQdx", etc.), but not configuration of the second page "Additional items you may want to install:", where it lists "recommended" items. This means one cannot create a fully customized NI Software suited installation (like was possible in the past with the .spec file).
NIPB needs to analyze the installer configuration and expose a list of recommends/suggests for each top-level package or for the whole installer itself, just like Install.exe does.
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.
With the NI Package Manager we can now create packages for a variety of purposes (libraries, tools, APIs, stand-alone applications, plugins...).
However, there's currently a limitation with the dependencies. For example, if you want to create a .nipkg file that relies on the LabVIEW Runtime Engine that successfully deploys to any PC, you have 2 choices:
- manually install the LV RTE from NIPM on the deployment machine
- add the LV RTE (and your app) to a custom feed, and manually add that feed to NIPM on the deployment machine.
In any case, there's a manual operation for a user. This is because NIPM does not automatically search for NI feeds when installing a custom package (it only looks into already installed feeds).
There should be (at least) an option like this in NIPM (ideally it should be the default behavior)!
This way, NIPM would behave pretty much like any other package manager (think Linux or mobile platforms)...