It will be cool if there is a menu option (right click, menu bar etc.) for building a package of selected VIs?

http://screencast.com/t/bZbEaDixH

With Project Provider mechanism, this seems feasible as well.

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

I have setup a post-build VI that checks all the changing files into our SCC.

However when I hit the 'Show package in VIPM' VIPM will resave the VIPB file with the new (for next build) version information, leaving me with a dirty project.

It would be nice if there were no alterations after the post-build VI.

Ton

What is it?

currently you have the ability to add a file name prefix/postfix to all package files. I am proposing that we have the ability to add a file name prefix/postfix to ONLY the dependencies. This would be identical to the way that NI allows you to rename the dependencies in packed libraries.

Why is this needed?

When migrating your code into packages, you're presented with this series of events:

1. I have X.vi. It is some piece of re-usable code that hasn't yet made it into a VIP.
2. I build package A.vip and it has dependency X.vi included in the package
   
3. I have application Application.vi that has dependencies A.vip and X.vi 
   
4. Now, when i open Application.vi, I am unsure which X.vi will be used?!

With this change implemented, the series of events changes to:

1. I build package A.vip and it has dependency X.vi included in the package as A_X.vi (assuming you add "A_" prefix to dependencies)
   
2. I have application Application.vi that has dependencies A.vip and X.vi 
3. Now, when i open Application.vi, the application uses X.vi and A.vip used A_X.vi

for a full discussion of this issue, see this thread http://forums.jki.net/topic/2103-rename-vi-dependencies/page__gopid__5165

Problem Description: When I use the VI Package Builder, I can make a list of package dependencies, which becomes a .VIPC file in the root folder of VI Package.

There is even a button in the "Package Dependencies" section to "Open VI Package Configuration". This opens up VIPC editor, where I can explicitly select for each entry if I want include only the link to the VIP or the whole VIP.

After closing the VIPC editor I am still in the VI Package Builder. I makes me very confident that the settings I have made in the VIPC editor are valid for the VI package I am editing right now.

But apparently it not this way. It brings up some other problems, which are real problems (not just theoretical) to me:

If a VIP (call it a.vip) has a dependency(call it a_dep.vip) that is used in the Pre or Post-Install steps, than I start to have a dependency hierarchy. If a.vip is a dependency to a new new.vip than it's not enough anymore to just include the the a.vip and the a_dep.vip in a VIPC file with the new.vip. From this point on nothing guarantees that a_dep.vip will be installed before a.vip.

Idea:

...and maybe tell me about updates to packages I don't have installed?

When I scan my repo, it tells me that there are no new verisons of packages that I have installed. I think it should also tell me if there are any new packages avialable since the last scan.

I tried to create a VIP that contained the famfamfam.com Silk icon set as a glyph set for the NI Icon editor.

The Icon editor stores the PNG files in the '%Default data directory%\Glyphs' path. Unfortunately the %Default Data Directory% isn't available as a target in VIPM.

Ton

I would like the ability to categorize VI packages that are built.  If my company has 3 basic categories for a toolkit (1. use at own risk 2. Semi-tested 3. Certified). Then this category can be displayed when a user installs a package.  

Furthermore, once this information is gathered, you can then possibly search and install only Rock solid packages, for example

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

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?

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

Given the graphical paradigm of LabVIEW I think it would be sweet if I could click on an icon I see in the Insert >> LabVIEW Primitive... dialog to select it for the palette (rather than just text). 

Here is a quick edit (not complete) of what may be cool - to show all search hits with icons and text that could be scrolled through and double-clicked.

Just a small one... ...I think it would be sweet if the Insert >> LabVIEW Primitive... Dialog defaults to the previous search. 

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

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