Welcome to the VIPM Idea Exchange. Here's your chance to collaborate with JKI engineers and other users to influence the future of VI Package Manager. How can VIPM make your life easier or help you work smarter? Tell us!
To submit an idea:
- Type your idea in the box below. The Idea Exchange will show you similar ideas as you're typing.
- If someone else has already submitted a similar idea, vote that idea up and add a comment to the discussion.
- If they haven't, submit your idea as a new suggestion by clicking Next. Then provide a detailed description in the submission form. Add links, images, and video to make your suggestion clear and compelling!
To vote for an existing idea:
- Click the Vote balloon next to any idea to show your support. Better yet, also add a comment to the discussion.
- You will be prompted to create a new account if you don't have one, or login, if you do.
If you need technical support for VIPM or any of JKI's other products, click here.
It will be nice to have a property/option to exclude newly added folders from package by default. As of now any new folder under Source directory is included in package as default, It will be nice to somehow exclude new folders by default.
I have situation where I feel this option will be very useful.
I and my team are creating lots of Instrument drivers for internal purpose and release them very frequently. We have all our code under Instrument Driver folder. Instrument Driver folder includes sub folder (category of instrument drivers like Power supply, RF etc) and menu files that needs to be deployed while installing packages. With help of menu files drivers will be shown up in LabVIEW functionally palette.
Say to build Keithley 24xx, I need to include Instrument Driver as source directory and include Keithey 24xx folder and whole hierarchy of Instrument Driver menu files (ie the menu file directly inside Instrument Driver and the one inside Power Supply folder) and build package over it. Rest of the unnecessary folders are excluded from packages. Please see I need the whole hierarchy of menu files so that in the LabVIEW palette drivers are shown in the same level/folders as shown in window explorer (Instrument driver -> Power supply -> Keithley 24xx)
- Whenever a new folder or driver category is created under Instrument Driver, the next time in Keithley package, the new folder is included in the ‘Source file setting’ by default, which is NOT needed. So exclude folders by default will be helpful here.
- When there are multiples PC used for development purpose, there comes one more situation. VIPM removes file exclusions if source code folders aren't located on the machine where the build spec is being modified. So take the same example:
- A build spec is created on machine1 with this source directory: Instrument Driver
- Inside of that folder are several other folders: ...\Power Supply\Keithley 24xx, ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix.
- In the source file settings ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix are EXCLUDED from package
- The build spec is saved and closed
- The build spec is opened on machine2 that only has ...\Power Supply\Keithley 24xx folder
- VIPM will remove the folder exclusions properties of..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix (as folders are missing)
- The build spec is saved and closed
- The build spec is opened again on machine1
- The build will now include ..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix which were excluded first time but in the second build their properties were lost and now VIPM thinks they are newly encountered folders and include them by default.
This causes lots of issues and before each build developer has to verify the ‘Source file settings’ causing consumption of time.
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
Some similar preview might be useful for VI Package Configurations as well?
I recently gave a presentation on VIPM Professional to a room full of colleagues, trying to convince them that we should all own a copy. The question was asked "Would this tool provide me with a flexible way to search our reuse libraries for some functionality that I am looking for"? Alas, I had to answer "No". This would be IMMENSELY helpful!
When removing the block diagram from reuse VIs destined for the LV Dev environment, we limit that toolset for a single LV version obviously. Thus it would be nice to have the ability to build more than one package with a single build specification; one for each of a number of specified LV versions. Instead of specifying "LabVIEW 2012" vs. "LabVIEW 2012 or later", then maybe an optional selection list where you could tick of which LV versions to build for (resulting in N vip-files).
Or maybe I should just automate our dev process some more to do the above myself? Maybe I can use the VIPB API to do that...
This will probably require a new tag in the project file to specify where the dependencies package is on disk. It'll probably also require access to a new Filter event from LV that notifies some process/tool of an impending File Open operation. So I don't expect much out of this request, but I'd sure like to see it!
It would be awesome to be able to create these packages online and store them in our user profile. Consequently, having the ability to share package configurations between users (publicly or privately) would allow to keep small vipc files in LabVIEW project without the need to "include packages" in the configuration file.
VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:
1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.
2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.
I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.
My suggestion is to have the ability to put multiple versions of the same package into a VIPC. This way when I am installing it offline and not connected to a repository, where all package versions could be available. I could then use the same VIPC for 2012, or 2011, and in both cases I could have the latest version that is supported.
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.
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).
In this case, the "Palettes" tab in VI Package Builder is not used at all.
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.
This could be useful if you have to setup lots of computers with the same libraries. If a unattended way was provided, this could be put in scrips etc.
Especially in our case this could be a reason why we cannot use VIPM. I created a *.vipc file and imported them manually. This worked very nice and easy but I am not willed to do this on all of our computers. A in my opinion easy and usual approach could be to put the functionality in a command line argument. I.e.:
VI Package Manager.exe /addLibrary "C:\library.vipc"
I know that there is the VIPM API. The problem is, that this is usable with the pro version only. To install the pro version on all of our computer would be too expensive and never needed any more after this step.
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?
At the moment I need to go over each license and find afterwards that I actually installed a trial version or some other tool that I won't be able to use.
If VIPM could organize the packages not only by the name of the license type but also by a deeper understanding of it (there aren't that many license types in VIPM after all) then I'll feel much safer while installing packages from VIPM.
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.
- There is a API available (see VIPM idea here)
- I have access to the distributed location of the code before it is packaged
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).
I would be nice to have the ability to install a package directly into a end user specified project folder instead of being forced to install to a set location. This would be similar to how NPM manages dependencies for Javacript node.js projects.
I assume this package would not be installed onto any of the pallets, but it would allow a user to work with multiple projects using different versions of the same packages. You wouldn't have dependency overlap of installing things into your labview program files or OS user file locations. I guess this would just be an extension for packed project library but with versioning built in
After starting my build process, and waiting for about 10 minutes, it bombed with an error related to validation of the Automated Online Activation URL. This check is performed by calling "_ValidateAutoActivationURL.vi" from the NI_LV2PLicAPI.lvlib, and can therefore be done at any time. Can I request that this check is performed at the very beginning please? Thanks.
With most things you can download these days there's usually some form of user rating, namely in the form of a score out of 5 stars, such as
The best of the best
There are so many packages on VIPM now, and some I've never seen before and have never tried, that I wonder which ones I might be missing out on. I can't install them all, but if each were to display a star rating I could quickly pick out some candidates to try! I would know that these ratings would be coming from LabVIEW users and that I could trust them to be an honest reflection on the usefulness of the package.
NI Tools Network
The NI Tools Network already implements a ratings system, can we have something similar for the packages list view window? Clearly those that are supported on the NI Tools Network repository would need their rating to come from NI.
Of course, the ratings need to come from somewhere, and that would be us users. I think it would be great if you were able to provide your own rating for packages you have installed. If you are uninstalling a package, VIPM could ask you to provide a rating whilst it uninstalls so that you can provide feedback on why - it maybe that you hated it and this way you get to provide a low rating.
It will be cool if there is a menu option (right click, menu bar etc.) for building a package of selected VIs?
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.
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.
Is this basically a request for NOT autosaving? Just want to clarify.
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:
- I have X.vi. It is some piece of re-usable code that hasn't yet made it into a VIP.
- I build package A.vip and it has dependency X.vi included in the package
- I have application Application.vi that has dependencies A.vip and X.vi
- 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:
- 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)
- I have application Application.vi that has dependencies A.vip and X.vi
- 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.
...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.
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...
Customer support service by UserEcho