Your comments

i would find admin privileges at the package level useful.

i do not want vipm to run as admin. i would have to justify this to information security and that could give people reason to NOT use VIPM.

i have a use case for this. i am writing packages that edit registry settings to apply user preferences (e.g. windows settings, SVN preferences, etc). since VIPM is so easy to use, i would rather use it than a standard batch file because i can place multiple packages into a VIPC.

one thing to note is that a VI package is installed for all users. if you edit registry settings for the current user with a package, it will only be applied for that user even though the package will appear to have been installed for all users.
i would also find this useful.

to debug packages, we will edit the installed package files (in vi.lib) and then port over the changes to the package source code. to "unfix" the changed installed package files, we'd need to either re-install the package or upgrade to the newer version. this would make things a little simpler. perhaps adding a "repair all" option to VIPM would streamline this process. 

additionally, it would be helpful if all packages were "repaired" when installing a VIPC so that we have 100% confidence that the system is in the correct configuration.

i'm not concerned about this feature taking some time to execute. being in the correct configuration is more important.
i'm looking to specifically exclude the following:
  • documentation (requirements docs, communication protocol spec docs)
  • functional tests (has dependencies that we don't want the package to have)
  • unit tests
we would typically include some of these in the project to make them easier to manage so i don't think the project approach would be the best for us.

I would define dependencies as files that satisfy all of the following:

  • outside the source folder
  • not beneath labview
  • not in other installed packages
basically, i'm looking to rename all extra files included in the VIP that did not originate from the source folder.
This change should be completely transparent and backward compatible. Unless people are using these files that are not included in the palette.

this would give you the flexibility to override the default exclusions once they were initially applied. this isn't really a requirement, it is just nice to have the ability to override these things sometimes.


your implementation scenario pretty much nails what i'm looking for. an exclusion filter for each package would suffice.


if you go the route of a "default exclusion filter" applied to VIPM in general, that would lend to creating default settings for other things (e.g. default pre/post build scripts).  I like this option, but due to the complexity it's not a simple upgrade and therefore less likely to be implemented.