NI Package Management Idea Exchange

Community Browser
cancel
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.

Post an idea

When you create a solution with Ni Package Builder, you have the ability to create a Local Repository for a feed.

Everytime you build it it replace all.

 

For me, we missed a functionnality to update a feed. A feed is able to handle multiple version of a package, if you replace all, you lost the history.

Without this functionnality, you cannot mix sources of the package for the feed. In my case, I have a feed that contains package build with TS deployment tools and packages build with NI Package Builder. To include both packages, I have to build my own tool. If NI Pacakge builder was able to update existing feed, I can build all the packages of my solution and push it to the feed in one way.

 

Just hoping that i will have feedback !!!!

It would be super nice if NI would offer all their software through winget from Microsoft.

 

https://docs.microsoft.com/en-us/windows/package-manager/winget/

 

I understand that NI invested a lot in the NI Package Manager, so this idea could still simplify our lives even if NI would just offer to install the NI Package Manager through winget.

 

Currently, the flow is to:

  • Go to ni.com
  • Login (if not already logged in)
  • Go to the download page
  • Search for NI Package Manager
  • Download
  • Install

 

Using winget, a command like:

 

"winget install NI.PackgeManager"

 

would be the only thing to do to to install it.

 

Here is what's available currently through winget: https://winget.run/

 

It could be usefull to have authentication capabilities in NIPM in order to create private feeds. Feeds stored on Microsoft Windows folder / shared folders can use Windows authentication but there is nothing available for feeds accessed with HTTP requests.

 

Something like username/password or API Key in HTTP headers, if possible a mechanism to be compatible with all storage plateforms (AWS, Artifactory...).

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, -? ). 

With the removal of the Browse Products in NIPM 20.6, the main software download page should have search box that searches just the downloads. It would help replicate the older NIPM experience to quickly help people find the software that are wanting to install.

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 any package from ni, they are auto registering feeds for themselves and their dependencies. It will be good to add to feature so that when configuring and building a package, we can also specify a feed name and uri. The package will automatically register the feed when installing it, just like package from ni does. 

 

There is really no good way of auto-register a feed when install the package. NIPM API will stuck when running as an post install executable. The executable will be able to execute with no issue when run not at post install. The other way is to directly manipulate with the nipkg.ini which should really be avoided from end user.

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 :-))

I created a package in LabVIEW 2020 which (obviously) depends on LabVIEW runtime and other things.  When I create the feed from LabVIEW, it includes all of these -- Excellent!

 

I have additional packages that I want to create in NI Package Builder which are add-ons to the LV solution to support a Plugin Architecture.

I can include the LabVIEW package as a dependency (assuming it's installed), but when I create the feed, it does NOT include the nested dependencies.

 

It would be very nice to include an option for dependencies to "Detect and Include dependencies" 

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).

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.

There are situations packages may have conflicts with each other. If we can specify the conflicted packages in the package build spec, It will be very helpful.

 

This is an existing feature on JKI's VI Package Manager. It uninstalls conflicted package with the new install.

It would be nice to define "absolute paths" for packages, installer, and feed builds.

I applaud the relative path detection used (better than that used in LabVIEW builder!), but sometimes, I just need to define an absolute (In my case that path is actually defined directly off of a root drive (E:\Builds\...), so that all of my build artifacts are in a well defined location...

jyoung8711_0-1614989033788.png

 

Currently, there is an option to ignore all errors in a customExecute step.

However, if you are including an installer as a step, sometimes it returns code 3010 (which isn't an actual error). It would be helpful to be able to ignore the 3010 return code (for example), but not ignore others to indicate that the install was a failure.

It would be great if the feed-download command would accept parameters for:

  • Downloading a feed that's not in the current configuration (feed is in a directory)
  • Including dependencies in the download
  • Including EULAs in the download
  • Including recommended packages in the download
  • Including suggested packages in the download

It would be nice to create an offline installer that includes the NIPM bootstrapper installer from the NIPM CLI.

The installer payload would come from any of:

  • A feed in the current configuration
  • A feed from a directory on disk
  • A selection of installed packages
  • A selection of packages in a directory on disk

There would be options for indicating:

  • Which package(s) would always be installed
  • Whether to include Depends, EULAS, Suggests, and Recommends packages (resolved from current configuration and/or the source feed)

 

I've recently been able to do this with a ton of scripting but it would likely be so much cleaner and reliable if NIPM managed it all.

I ran into an issue where I needed cRIO driver set 19.6 for an older target, I only had 19.1 installed and a whole bunch of newer sets. 

The should be an option to install driver sets (for installation to a target) regardless if newer sets are installed. Not every customer uses the latest and greatest cRIOs.

I am building a custom offline installer for LabVIEW and Teststand and share it with people in my organization. I created a single installer which included both 32-bit and 64-bit LabVIEW versions and few add-ons that are required for the tools that we developed. The problem I see is if the user selects one version of LabVIEW, the add-ons for that bitness alone has to be selected automatically. But there is no option to specify such dependencies in the Package builder

In distributing software to customers (particularly through an IT group), a lot of the NIPM interaction ends up happening through batch files in an automated way.  In these types of instances we're running into either:

a) we want a hard lock on the software version (software is propagated through internal feeds) or

b) the system may have intermittent/limited internet connectivity or a proxy is in use.

 

When installing NI products, release feeds are automagically added to the feed list... and I REALLY don't want them there.

 

There's a nice GUI button to disable this... but again... trying to do thing as "hands-off" for the user as possible.

 

Supposedly this used to be possible through editing a config file:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015CMrSAM&l=en-US

 

But as of 20.7.X this method no longer seems to work.

 

It would be great if this could be added to the CLI interface or contained in some sort of accessible file that can be manipulated.