Project Template Dependencies Best Practices

[dcoons]

For a lot of my LabVIEW projects, I have been developing scripting tools to help team members get to a good starting point for their code or to remove human error when following templates.  After seeing Becky Linton's presentation at NI Week in 2016 (link), I was inspired to use Project Templates to make it a little easier for the developers to get to.  I have been able to get it to work to varying degrees at this point, but I have a question on how to handle project-specific dependencies.

If I have a team working on a larger development project that has shared core code and we have it in a repository, everyone on the team usually puts the cloned source on a different location on disk.  If my scripting tools have a dependency on code in that repository (class ancestor is biggest), then its location would move from development machine to development machine.  Therefore, if I put my tools into the LabVIEW\ProjectTemplates directory, those dependencies would need to re-map for every user and that defeats the benefit to having it be a part of the Getting Started window - at that point it is easier just to point them to the scripting wizards that are pulled with the rest of the code from the repository. 

Does anyone have a good suggestion for how to accomplish a good structure with project-specific dependencies?  Or am I trying to fit a square peg into a round hole for this type of application?

[smithd]

I've never done it that way, for shared dependencies I've always made packages and installed them into vi.lib, which eliminates the problem. I don't think there is an easy fix.

The fix I can think of is that there are several steps to the sample project: a dialog is displayed, then it copies the sample project into a new location, then it runs any post-copy scripting code. My suggestion would be to ask your users, in the dialog, where their 'root' project directory is. You can then through either the default value vi, or that same VI loaded up in a more appropriate application context (you may need the super secret ini key turned on to find the right one), get the ancestor classes loaded in from the appropriate path. Once they are loaded, and you reach the copy part of the script, labview should accept that they are the right ones (it might fuss that dependencies were found in the wrong location, but it should work). 

Another route would be to just make a tools menu item which replicates the sample project script, but with your particular variations like asking the user for their main directory -- that would be my workaround if labview does weird stuff with application contexts when its copying the project over. I don't know the exact procedure.

Edited October 13, 2018 by smithd

[Darren]

+1 for installing shared dependencies in vi.lib with VIPM packages. Makes this sort of thing much easier to manage than having each project have their own copy of the reuse code.

[Stagg54]

14 minutes ago, Darren said:

+1 for installing shared dependencies in vi.lib with VIPM packages. Makes this sort of thing much easier to manage than having each project have their own copy of the reuse code.

If you do this for external dependencies and everything internal to the project uses a relative path, then your coworkers should be able to check it out to whatever directory they want and not have any issues.

[Stagg54]

oh and if your tools need to know what directory things are checked out into, you can always add it to the tools menu.  Make them invoke it with the project open and then can pull the items you need out of the project or just use the current project path and compute everything relative to that.

[dcoons]

On 10/12/2018 at 4:26 PM, smithd said:

I've never done it that way, for shared dependencies I've always made packages and installed them into vi.lib, which eliminates the problem. I don't think there is an easy fix.

The fix I can think of is that there are several steps to the sample project: a dialog is displayed, then it copies the sample project into a new location, then it runs any post-copy scripting code. My suggestion would be to ask your users, in the dialog, where their 'root' project directory is. You can then through either the default value vi, or that same VI loaded up in a more appropriate application context (you may need the super secret ini key turned on to find the right one), get the ancestor classes loaded in from the appropriate path. Once they are loaded, and you reach the copy part of the script, labview should accept that they are the right ones (it might fuss that dependencies were found in the wrong location, but it should work).

I think I am comfortable with the idea of creating packages and putting into vi.lib - that is a good idea except there is one dependency library that is a little different.  The one that I am not sure about is a plug-in type that loads the correct child plug-in based on the configuration file for the application.  So for that one I would still need to do a little directory trickery.  I will do a little playing around and see what I can get to work (and I will try to remember to reply back with how I handled it).