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

Hi,

 

While trying to automate the building of packages of custom devices I found out that there was no practical way to automate what version the package should have (modifying the xml was not streightforward due to multiple namespaces)

 

The package builder manual shows "-v" command line option, but that will just print the version of the ni package builder itself. 

 

I want to propose that a "--set-version" command line option is added, which takes a "x.x.x.x" formatted string and would overwrite the <Version> tag in the .pbs file.  

 

Thank you!

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

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

It would appear that NI Package Manager requires elevated privileges via User Account Control to even run.

Whilst clearly for some actions this will be required for some install/uninstall actions and e.g. changing registry entries, it isn't clear why this is needed simply to open Package Manager to view what is installed and for other actions which may only make JKI VI Package Manager type changes to VIs within vi.lib etc.

 

If the medium/long term plan is for NI Package Manager to replace JKI VI Package Manager then it needs to support the ability for developers to easily add/remove VI packages without requiring IT administrator assistance each time.

It would be much better if the application was structured such that elevation is only required when this is absolutely necessary for the actions being undertaken at that moment and/or the user is able to explicitly run the application with elevated privileges where these will be required.

I did try to post this in Additional NI Software Idea Exchange and that wasn't possible but please move this should there be somewhere more appropriate.

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

When you have an update available for a package, you cannot access the details of the package. So you don't have access to the detils of the update. You must manually find the corresponding package in the product view and select the version to install to have access to the details.

 

At least a way to access to the product details page from the available update page.

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

[Edit: 2022-May-10] Moving to LabVIEW Idea Exchange as NI Package Manager and NI Package Builder support custom category values.

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

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.

There should be a refresh button added to the NI Package Manager GUI. There is the ability to refresh the listings by pressing the F5 key, but that is not discover-able by the user other than blindly trying the defacto key.

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.

It would be nice if NI Package Builder could detect and prevent Windows path length limitations. Since where a package solution is built and where it is installed can be different, they typical building of the folder structure to be packed can run into the Windows 260 file path character limit. I would like if NIPB could detect that this will happen and relocate the packing folder automatically to avoid the issue. I would recommend a warning is issued; also, I have no issue that it might take longer to build as it would try and fail then redo in a new location.

 

Example:

image-2020-01-02-16-02-37-354.png

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

During installation, we cannot minimize NI Package Manager (NIPM) window even if the window has "_" button at top right of the screen.

I guess this is because the instalaltion window is set to "modal" so, we cannot touch NIPM window.

 

In addition, we cannot move NIPM window. The window hides my desktop icons so, it's annoying.

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.

I'd like to suggest that the package manager be updated with a feature to download an offline installation directly, instead of installing on this machine. It would be more convenient to use the package manager to gather the software I need to install on offline machines rather than trying to search the NI website. Then, for some products, I have to install it on my machine first, then create a feed from that installation to move to another machine, a direct offline download would save a lot of time and frustration trying to gather everything for offline machines.

Ability to request to be (automatically) notified via email of patches and updates to a particular software or driver package.  NI Package Manager will only give me updates if I am online and for software I have installed.

 

 

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.