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

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.

The old installer had an option to remove all NI Software via the command line:

Automating Uninstallation of NI Software - National Instruments
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LfWSAU&l=en-US

 

While the nipk  command line interface has the "remove" option there is no "remove all" feature. It is only possible to remove single packages.

We desperately need the ability to install the same package to multiple versions of LabVIEW. Specifically, we need support for symbolic paths as a destination (user.lib, vi.lib, instr.lib, etc). 

Basically duplicate the VI Package Manager's ability to install a package to multiple versions of LabVIEW. I think the VI Package Manager work flow should be duplicated as well.

 

FYI: 

https://labviewwiki.org/wiki/Package_Manager_Comparison

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.

I propose to add pre- and post build actions to the LabVIEW package build spec as already present in e.g. executable build spec

I'd like the option to uninstall a package form both the ui and viia the command line but NOT uninstall its dependencies. see 

https://forums.ni.com/t5/NI-Package-Manager-NIPM/I-want-to-uninstall-a-package-and-NOT-uninstall-its...

for details.

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:

https://labviewwiki.org/wiki/Package_Manager_Comparison

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

As discussed in this thread, it would be helpful to be able to programmatically change the NI Package Manager settings. I personally am interested in changing the highlighted defaults. Maybe this could be done via the NIPM command line interface. Or a setting file, so it could be deployed as a NI Package.

2019-11-19_18h50_02.pngSettings of Interest

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.

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.

2019-07-25_11h45_46.png

When creating NI Packages with NI Package Builder, you are currently stuck with the limited set of categories/sections. It would help if we could customize this field.

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

NI Packages have attributes for Homepage and Maintainer's Email as listed in the control file. It would be nice to at least have an option to display the information in NI Package Manager.

displaying the package size in the feed list can give user an idea when to schedule installations/updates based on their network traffic trends, like in Update Service

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.

 

Current NI Package Categories/Sections

2019-07-08_14h18_38.png

GitHub Releases is a place where we can host downloadable packages for our projects.

 

NI is already using it:

https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/

 

Each package is given a nice clear URL like
https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/download/v19.0.0/ni-sc...

 

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:

 

Architecture: windows_all
CompatibilityVersion: 190006
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
DisplayVersion: 19.0.0
Eula: eula-ni-standard
Filename: https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/download/v19.0.0/ni-scan-engine-veristand-2018-support_19.0.0.11_windows_all.nipkg
Homepage: http://www.ni.com
LanguageSupport: en
MD5sum: be9d301d98465ac3157fbb8b6cee370b
Maintainer: National Instruments <support@ni.com>
Package: ni-scan-engine-veristand-2018-support
Plugin: file
Priority: standard
Section: Add-Ons
Size: 38198876
UserVisible: yes
Version: 19.0.0.11

 

 

Alas, although NIPM accepted the feed, it did not allow the package to be downloaded ("Redirection to another URL is forbidden"):

 

nipkg-redirection-forbidden.png

 

It turns out that the nice URL above actually redirects to an Amazon cloud storage location, and the final URL is like

https://github-production-release-asset-2e65be.s3.amazonaws.com/150638172/d0544200-8d25-11e9-9a52-58...

 

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.

 

(originally posted in the NIPM forum)

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

NIPM of offline SPB images to allow RTE to be installed independently without having to install the LV development package. Imagine the user is keeping the SPB image (which is supposed to have almost all software packages) in company server, only to find out that the RTE cannot be installed at end user PC without having to install the development package. and offline package installation that is supposed to be offline, is subjected to poor internet connection. my attempt failed 2 hours in... Smiley Surprised , have to resort to individual RTE download soon after...

 

better still if NIPM can capture the "missing RTE" dialog during application launch and launches itself automatically with option for users to point to local repository locations for "off-lined" offline installation 

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.