Make the LabVIEW "resource" folder a symbolic path

[vishots.com]

I don't want us to open a door that most users can walk through just for the sake of the very few who are developing providers.

Wasn't a similar argument made for not releasing VI scripting to the public? The people that link to resource are expert users already. Provide enough qualifiers and warnings.

[Jim_Kring]

Hey AQ,

For the moment, I'm going to avoid the question about whether VIPM should allow packaging stuff under the LabVIEW directory...

The fundamental problem is that developers should be able to keep their provider sources outside of LabVIEW, in an arbitrary location, but they can't because providers need to call VIs under the resource folder.  As a general rule, add-on developers shouldn't have to keep their source code under LabVIEW, and especially not in the the final installed location.

Another solution to the above problem (besides making "resource" a symbolic path) would be for NI to move any "provider API" VIs (the provider framework VIs that a project provider add-on must call, in order to interact with the framework) into vi.lib (or some other location that is under a symbolic path).  I'd be happy with that solution.  But, if add-ons are required to call VIs located under "resource" then it needs to be a symbolic path.

Now, why doesn't VIPM allow packaging stuff under the LabVIEW directory?  The basic reason is that we want to discourage users from keeping their source code under the LabVIEW directory, because they could build a package and then install it on top of their source code.  Also, whenever VIPM builds a package, it excludes VIs found under the LabVIEW directory, since these are dependencies.  Additional logic could probably be added to make VIPM smart enough to handle the situation where the VI Package sources are under LabVIEW, but we've never really had any compelling use cases that couldn't be solved by just moving the sources out from under the LabVIEW folder (which we believe is better for users development practices, in general).

-Jim

[AristosQueue (NI)]

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?

[AristosQueue (NI)]

MichaelAivaliotis wrote:

The people that link to resource are expert users already. Provide enough qualifiers and warnings.

It's not about whether you're expert or not. I don't want any user, expert or otherwise, writing code that they expect to link to in future LV versions. We have pseudopaths in order to give a directory version independence. Since resource is not meant to have version independence, I claim it should not have a pseudopath.

[Jim_Kring]

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

[Arif Saikat]

Instead of making the entire ‘LabVIEW\Resource\’ directory a pseudopath, we are trying to figure out what subdirectories under ‘LabVIEW\Resource\’ might be good candidates of being part of a pseudopath. It looks like all the provider related contents are within ‘LabVIEW\resource\Framework\Providers\’. What other subdirectories under ‘LabVIEW\Resource\’ you think might be useful being part of a pseudopath?

[Jim_Kring]

That's the only one that I can think of, right now.  However, there are other locations where developers install add-ons, such as the "LabVIEW\wizard" and "LabVIEW\project" folders.  However, typically, VIs that get installed into these locations are not called by other add-ons.

Also, how about adopting an official LabVIEW standard that all internal APIs (that LabVIEW add-ons call) must be located under "LabVIEW\resource\Framework"?

[Mattias_Ericsson]

Hi,

Our project provider toolkit G# Framework uses the following directories:

Installs VIs here:

LabVIEW\resource\Framework\Providers\ (main toolkit code)

LabVIEW\resource\plugin\CreateSubVI\ (hook to create sub VI)

LabVIEW\project\

LabVIEW\help\

Uses VIs here:

LabVIEW\resource\Framework\Providers\API\ (support for project provider)

LabVIEW\resource\Framework\dialog\lvconfig.llb\ (uses these too read LabVIEW.ini for user settings)

Hope this info helps!

Thanks,

Mattias

[vishots.com]

It seems that this hasen't been closed off. I just want to let everyone interested in this thread to know that <LabVIEW>\resource\ symbolic paths have been added to LabVIEW since version 2012.

[JeffBoettcher]

Good point Michael!

Just to be a little more explicit about what that means for posterity:

In LabVIEW 2011 and earlier, <resource>:\blah.vi was meaningless, and a VI that called a VI in the resource directory would reference it by a relative path.

In LabVIEW 2012 and later, <resource>:\blah.vi resolves to <LabVIEW>\resource\blah.vi, and a VI that calls a VI in the resource directory references it as <resource>:\blah.vi, in the same way it would <vilib>:\blah.vi if it is in vi.lib.