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 !!!!

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

Right now I can only add package dependencies that are either 

(a) Currently Installed

(b) In the solution being created

 

It would be extremely useful to:

(a) Select a package dependency from disk

(b) Select a package from a currently registered feed

 

On a development system, I often DON"T want to actually install the packages i'm developing, and if I have several related "solutions" I need a way to define dependency relationship between them.

 

Right now I either have to develop everything in the same solution (which means every time I build, it builds everything), or am forced to install the packages that I want to include as dependencies.... neither of which are desirable behaviors

Hello,

 

I want to distribute my packages with a specific feed. This can be very usefull to distribute application to customer and push updates. But if we use a specific feed, it's not straightforward. We can use the nipkg CLI command to add/remove the feed but it's not so easy to deploy to customer. It's often more easy to request IT to let NI Package Manager to have Admin right than to allow bat file for example.

 

So my idea is to give ability to install a package that also register the feed. After install the package, it can have access to updates more easily. If he uninstall the package it can interresting to unregister the feed. In this way, it can be also easy to update the feed by pushing an update of the package.

 

Note : I tried to do it with pre and post install command without success.

 

Best regards.

 

 

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

This feature is available in the LabVIEW package builder (very cool!), but it would be helpful to have this exposed in the NI Package Builder UI as well...

 

Currently my work around is to either

(a) Use the SystemLink REST API and (really requires a good development pipeline for automation)

(b) Target the feed at the SystemLink internal repository folder, which will create a "hidden" repository that is unavailable in the SystemLink Browser, but can still be referenced... While not too terrible for testing, this is probably not a great approach from a security point of view...

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.

In the Item View, if some files are insert in a folder, you need to open all folder to make sure your solution is up to date :

MaximeR_0-1607090694572.png

 

Why not add the Blue Dot to the folder too :

 

MaximeR_1-1607090878057.png MaximeR_2-1607090907881.png

 

I don't know also if it's a good idea to allow to have file in multiple location in this view. This can be confusing.

 

Regards

 

 

 

 

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

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" 

Hello,

 

I used to distribute a software with non-package installer. Then, we switched to a package installer. It is built using NI Package Builder.
Unfortunately, NI Package builder doesn't uninstall previous versions as it doesn't know the relationship.

 

Please, could you implement in the UI the possibility to specify "conflicts" and "replaces" relationships as described in this document?
http://www.ni.com/documentation/en/ni-package-manager/latest/manual/control-file-attributes/ 

 

Also discussed on the forum: https://forums.ni.com/t5/NI-Package-Manager-NIPM/Nothing-but-confusion-about-building-and-using-packages/m-p/3938499/highlight/true?profile.language=fr#M91 

 

Romain

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

 

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.

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

You can add folders to the "inputs" in NIPB, and they will auto detect if files have been changed / added to the solution.

 

If you ad a folder (or a complex folder hierarchy) to a package, it disconnects ALL of the folders.  I completely understand why this might be done, but it creates a slightly unexpected disconnect between the "inputs" and the "package workspace"

 

If files are updated, those updates propagate between both locations -- Great!

 

If files are added, those updates propagate to the Inputs, but NOT the workspace.

 

This can be pretty frustrating, especially for deeply nested folder structures...

 

My request is not that this is entirely switched, but rather an option to add a linked folder to the workspace... My thought is that this would function much like the "autopopulating folders" from labVIEW (vs snapshots) -- Though it would be nice if the base added folder could have it's name changed and still maintain the link (though not required).

 

 

The Control File Attributes page shows as an example near the bottom the following:

In the following example, the Depends attribute declares a dependency on package01 version 2.2.1 or later, and states that package03 is an alternative package that satisfies the dependency on package02.

Depends: package01 (>= 2.2.1), package02 | package03

 

However, it doesn't indicate which package will be (automatically) installed if both package02 and package03 are available in feeds, and neither is installed.

 

If the first is always the chosen package, can this please be clarified in documentation?

 

If the order does not determine the package (but instead it depends on the feed, etc) could this either be

a) changed to order, or

b) clarified in documentation along with some manner to manipulate the preference? 

Since NIPM creates/uses a custom/unique folder in %temp% for [Temp] files, it would be helpful to be able to create symbolic link to a file in [Temp] to be used in the custom executes. I ran into this trying to deploy a MSI installer with NIPB. If I had a way for NIPM to fill out the actual path to the .msi file in [Temp] in Post-Install action, I could easily have the msi installed silently and let NIPM delete the file aftwards for me. Instead I had to place the file somewhere else, [BootVolume], call install via Post-Install with my known path as an argument, and add a Post-Install All to delete the now unneeded .msi installer file.