We like having our dependencies copied into the project. As much as possible.
First reason is to be able to have different versions “installed” for different projects on one machine.
Second reason (more philosophical): We're of the firm opinion that a central repository is a bad hack from times when disk space was still expensive. There's absolutely no reason to mix or share dependencies in a single location from a project point of view, it only brings the potential of errors introduced without even being aware of it.
The downside of this strategy is that we must refrain from using VI Package Manager as it doesn't support installing into user-defined locations or installing multiple versions of packages into different locations.
At the time of writing (2020), we are looking into facilitating G Package Manager.
We use our own Release Automation Tools for server-side automated execution of various actions. Reuse libraries are built into release packages: .zip archives containing the source distribution build results.
For any project, we take the release packages and extract their contents into the project directory. This way, the built code (eg VIs with version numbers in their context help) is made a part of project itself.
We only use git submodules where we think that we want to implement modifications to reuse libraries within the project and push back those modifications to the original repo of the library.
Hence, the only exception to HSE reuse libraries is the hse-application-template. As we develop or test many of the new features of the hse-libraries from within the
hse-application-template, they are added as git submodules there.
We build VI packages for generic (i.e. unrelated to our hse structures) reuse libraries, because people are used to that way of working. If we need different versions, we fall back to our own HSE release packages.
Examples for generic open-source projects with VIPM support are