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

think NI should allow the already stable and robust Update Service to download the latest packages/update and install them, while continue to fix/upgrade NIPM, Shouldn't put all eggs in the same basket. The current and recently updated NIPM is so frustrating that it can fail before initiating the download. the previous version kicked the bucket after hours into downloading, failing within inches from the finishing line. please consider not all users have fast and reliable internet connectivity.

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 be nice to be able to customize what is shown in the NIPM installation window while a Custom Execute is running. Frequently I am calling cmd.exe to run custom actions, so the executing cmd.exe is not very helpful as that is just means to calling something else with arguments. I would be helpful to be able to give a better description to the users of what was happening during that call. I would be ok if it was just an addition to what is shown now.

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

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.

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 => Smiley Surprised

 

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

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.

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

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. 

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.