Hi AQ,
AristosQueue wrote: Jim: Your argument for having the code not be under LV is reasonable. My second two alternatives allowed the source code to not be under the LV directory. What about those? |
Sorry that I didn't address those two options. I was time-limited when I responded and I thought I would address some of the more foundational assumptions.
> Option 2: Continue to require the source files exist outside LabVIEW in directory XYZ. They are going to be installed into directory <labview>\resource. When VI Package Manager loads the VIs to build them, why not just set the VI Path to be the path they will eventually be saved at, so that when you serialize the files, they save with the correct relative paths?
I don't totally understand this -- what do you mean by "set the VI Path"? Are you saying that VIPM could save (the only way to set a VI path in memory, that I know of) the VIs into their installed locations? Or, are you saying that VIPM would write to the VIs' linker info at the end of the build process? If it's the former (saving VIs to their final, installed location), then that could run the risk of overwriting VIs that are already installed. If it's the later (writing linker info), then I think it might be a problem, because I think that the write linker info function requires (verifies) that VIs actually exist in the target locations -- it's not possible to write linker info of locations where files will exist in the future (if they are not already there).
> Option 3: Continue to require the source files exist outside LabVIEW in directory XYZ. When VI Package Manager loads the VIs, it detects any subVIs that are inside LabVIEW and not at pseudo paths and makes local copies of those VIs in the correct relative positions with the source files, but leaves those files out of the package.
This might work (in theory), but it's quite a bit of gymnastics for the build process and there could be gotchas along the way. And, it seems like too much work, especially compared to how easy it would be, and how many problems it would solve, for users/VIPM if the resource folder were a symbolic path -- it seems like it would untangle a massive knot of several intertwined issues. Granted, it might make it less painful for users to link to things that might change in the future.
> A pseudopath link encourages people to use the stuff in vi.lib --- that's why we have the pseudopath link. The lack of one discourages use of the items in the resource directory unless (A) your code is being installed into the resource directory or (B) you make a copy of whatever the subVI is for your own uses.
Just to be clear: the only way it discourages people is that, when they open their project in a new location (relative to the resource VIs) LabVIEW searches for the missing VI. Is that right?
Do causal users actually go rummaging through the LabVIEW directory trying to find VIs that they can call in their projects? It seems that somebody with enough experience and bravado to start digging around the resources directory knows that stuff in there is not stuff intended for their casual use and could change.
Are there other/better ways to inform users which VIs are OK to call and which are not?
- How about making the resource directory a hidden folder in Windows? It seems that doing this would be almost trivial and would keep out novice users.
- What about putting a text file name "- WARNING - THESE VIS ARE NOT INTENDED FOR USERS -" in the resource folder (the hyphen will float the file to the top of the alphabetically sorted list).
- Could LabVIEW warn users, when they place a "resource" VI onto a block diagram, that the VI is not intended to be called and is not supported by NI?
In general, it seems that use of Libraries (and scoping off-limits VIs as private) is the way to go.
Bottom line: It seems to me that the benefits of making "resource" a pathroot, and making it easy for LabVIEW add-on developers to extend the platform, has far greater upside than the downside of some very small fraction of brave users experiencing missing/changed VIs that they call in thier projects -- especially considering that there's value to those users in being able to call those VIs in the first place, and that they can actually fix the problem (when/if it ever occurs) by going into the older version of LabVIEW and making copies for themselves, after the fact.
-Jim
