My VIPM Package Table has so many entries now that I have to scroll up and down to view all the entries.  I was thinking that a Tree View of the packages would make it easier to view and organise.

For instance the OpenG Package would be the root folder and clicking on this folder would show all the individual packages ie. Array Library, Boolean Library etc..

I think it would be really cool if a dynamic palettes (I will call it that after the OpenG package name, but there maybe a better descriptor for it?) were a first class feature of VIPM. There would be nothing better than being able to open up a native LabVIEW palette and being able to select from your code - all conveniently in the one place just like the OpenG ogrsc_dynamicpalette package does for OpenG etc...

I thought a cool new feature would be to allow adding multiple files on Insert... >> VI... to the Palette Editor instead of one at a time (and opposed to the entire folder). 

So I have a lightbulb moment today: why do I have to switch from LabVIEW to VIPM to build packages? Why can't I right click on a package build definition in my project's "Build Specifications" and either edit the configuration or build it directly from there?

I not sure if this got bought up before (in the beta?) but I would like a better UI for interacting with dependencies then there currently is. I just find it hard to find what I want unless I know the exact spelling of the package name (VIPM 3.0) or display name (VIPM 2010) and scrolling through everything is not that fun 

Sometimes my source for folder has old (or not yet finalized) VIs that I don't want to distribute, in my project I remove these VIs from the library/class, but since VIPM picks a whole folder as the build-source these VIs show up in the package. 

By selecting library or class as the build source these functions wouldn't be included.

I ventured into the wonderful world of VIPM package building recently, and am impressed. However, one thing that immediately caused me issues was the use of a Source Folder as the root of the package definition. I wanted to point VIPM at my existing LabVIEW Project. Why? Because in my harddisk folder I have VIs not included in the Project, legacy files and VIs no longer in use. When pointing VIPM to the root folder it automatically picked up all these unwanted files, and it was a nightmare of "build error" after "build error" attempting to find them all and selectively remove them from the "Source File Settings" tree.

Idea: Can VIPM analyse the LabVIEW Project tree in the first instance of creating a new package to determine which VIs (files) are wanted and which are not to initialise/populate the Source File Settings?

I ran into the situation a few times when I wanted to abort what I was doing but couldn't. This seemed to be for network tasks. I thought it would be cool if I could abort these in the future.

I have built a number of internal libraries where I want the same support on desktop and RT palettes. This involves recreating the palettes from scratch currently.

There should be an easy way to have the same palette on both.

Have been playing with the Custom Category and I really like it. 

In VI Package Builder I'd like to be able to specify a less-than-or-equal package version in the Incompatible Packages section.

The use case is this:

I update a low-level reuse VIP A, breaking compatibility with some of the VIPs that depend on A. Currently (VIPM 2013), in A, I can only select Incompatible Packages with versions "greater-than-or-equal", or "equal". What I'd like is for the VIP A installer to tell the user that they must upgrade their already installed VIP B, that depends on A, if they want to proceed with upgrading A. To do that I need to be able to specify package B from a version downwards as an Incompatible Package in package A.

Makes sense?

Cheers,

Steen

It would be really cool if I could add multiple dependency packages to a package as sub-packages so I could ship one package that contained all required packages. 

I can currently do this with a .vipc file, but love the idea that a package could do it.
Another good reason for sub-packages over .vipc files that I forgot to mention: .vipc files currently have to be installed in the same version they were created. For example, this means that to support multiple versions of LabVIEW for a package release, I have to add multiple .vipc files if I want to include dependencies + package in a .zip release. 

To start with I don't mind if its not exposed through the UI - as I would more than happy to do it myself with hooks. 
Backwards support for OGPB would be nice too.

It would be awesome if there were a way to programmatically read the contents of a VIPC file. I don't know that there's a way to do this yet using the VIPM API

This may be an edge case not worth the time but I thought I'd throw it out there. It would be nice if you didn't have to wait for the Palette Dialog to refresh if you have already opened it. A refresh button could force an update or it could refresh after each install (in the background could be nice). 

when creating a new VIP, automatically "exclude from build" folders that match user-defined strings (preferably compatible with labview regular expressions or PCRE). I suggest this because we have a well-defined file structure in our source code repository. all files in certain folders are never included in the build because they are only used during development. It would be nice if this could be auto-configured but only when creating new packages (so there are no surprises when opening an existing package).

The show in palettes button in the package information dialog does not support xctl? If only xctl is added to the controls palette without ctl or vi, then the button is disabled after the package is installed.

I built a hardware driver, all VIs are part of a library. The library contains some unit testing VIs which I don't need as a part of the VIP distribution, so they are marked as "Exclude from Package" on the Source File Settings section of VIPB.

However, as these VIs are a part of the library, when excluded from the build they cause the library to list them as missing dependencies when the VIP is installed on a development machine (the little yellow exclamation marks in the Project View).

If I move the VIs to outside the library this creates scoping issues with certain private dependencies only accessible from within the library, so they must remain within the library.

Ideally, VIPBuilder would repair the library by removing these dependencies safely within LabVIEW (not just excluding the files from the package) and thus maintaining library integrity. Maybe his can't be done.

But can I ask, what's the proper way to exclude VIs from the package that are listed as belonging to a library without the library becoming bad?

When i quickly want to have a new LabVIEW installation on another PC or VM, I can let run the LabVIEW installation unattended, but then it takes quite some presence-time to re-install all the VI packages with VIPM. So I usually just copy the whole LabVIEW user.lib folder over to the new VM. While LabVIEW gathers/auto-populates the user libraries automatically and the packages vi folders show up as palettes, VIPM doesn't do this, what in my eyes would be expected behavior. The whole VIPM packages list stays empty even though all the packages are there on disk. But maybe I oversee something, and there is already a way to make this auto-population happen...?