What, if anything, should intentionally be left as a Dependency in the Project Manager?

[Ryan_Chamberland]

I've read and heard some opinions stating anything between nothing at all should be left as a dependency, to any kind of shared library, (.lvlib, .lvlibp, .dll), instrument drivers, etc. should be left as a dependency. What are the best practices for managing project dependencies in LabVIEW when working with code shared among multiple projects, and why? Would there be a time where it would be considered best to not explicitly include code not shared among other projects? Interested in hearing perspectives in terms of project load time, edit-time latency, future project management, etc.

Thanks!

[jlokanis]

I never leave any code that I wrote in the dependency folder.  That includes reuse code I keep in user.lib.

I do leave any NI code from vi.lib and 3rd party reuse code (OpenG) in the dependency folder, as well as dlls and other non G components.

My rule is if the item is part of the standard dev environment on our workstations then it can be left as an undeclared dependancy.

I do not have any particular performance reasons for doing it this way.  It is just the way I decided to organize things.

[swatts]

I'm probably chief trouble-maker regarding dependencies here.

We try and remove as much as possible.

So....

Instr Lib

User Lib

and even VI.Lib if it has been modified (for us it's the ftp toolkit).

Generally we want our projects to be portable and dependent free, direct from the repository to a machine.

If feasible we would also like NI Drivers too, but currently it's not really feasible.

This is based on practice and not dogma, our many and varied projects benefit from this.

Our use-case is that we should be able to install our projects from our repository and  into a standard LabVIEW install with no extra libraries or installs.

I have various articles on my blog about this. Index here

Random Ramblings on LabVIEW Design - Index to Articles

Hope that helps

Steve

[James_McN]

I agree about project portability. However, I take a slightly different approach.

I keep a VIPC file and any additional installers in the repository. If a library is not available as either it will go in as source with a text file of where it came from.

Pros

* I also get version tracking and can see when upgrades are available.

* I get license tracking (I know what license terms everything is under)

* No cross linking worries (though as many have stated, they have been successful with other methods and avoided this anyway)

Cons

* Need VIPM pro

* Still manual process to remember to install when switching projects and checking for updates

It's a long way from perfect but thought I'd mention to add another into the mix.

[drjdpowell]

I wrote a unit test that doesn't actually test; it records in the test results a list of all installed VIPM packages and also copies those packages to a folder in the repo.  This means I can always recover the version of those packages present at each release (though not as easily as Steve's method).

[Gregory]

I try to only have dependencies from vi.lib. Sometimes I will have dependencies from instr.lib if it is an NI product (e.g. NI-SCOPE). Any other instruments I treat as a re-use library, and each re-use library gets copied to the project folder along with a text file that simply has the version number in it.

I don't think it matters too much as long as you are consistent and any other LV developers you work with are on the same page as to whether a project should be self-contained or if some dependencies are installed as part of a station set up protocol.

[swatts]

That's pretty much what we do Gregory, you raise a good side point tho' and it's a question that's not used enough.

"What problem are you trying to solve?"

If the way you handle dependencies (or don't) works for you, I would stick with it. Our particular use case as systems integrators is that it's crucial that our projects and libraries are very independent of each other.