We like having our dependencies living inside the project directory. 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 Package Managers that don't support installing into user-defined locations or installing multiple versions of packages into different locations.

At the time of writing (Nov. 2020), we are extremely excited about JKI's Project Dragon tool - see below!

We use our own Release Automation Tools for automatically creating releases. Our 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 from within the project we're working on.

An example of where we don't use the exported release package of our 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.

Depending on the packing mechanism used, it's not possible to change or even view the source code (i.e. block diagram) of the packaged library. This requires the library to be in a very mature state. While working with mature libraries is desirable, in reality, we find it useful and sometimes necessary to be able to view, debug and modify code when it makes sense.

When using source distributions instead of built (binary) packages, we specifically trade rigidity for the flexibility to move forward with the application, rather than awkward workarounds of a fixed interface to the library.

We build VI packages for generic (i.e. unrelated to our hse structures) reuse libraries, because VIPM is the de-facto standard way of working for most of the community. If we need different versions of these libraries, we fall back to our own HSE release packages.

Examples for generic open-source projects with VIPM support are

• the GitLab API for LabVIEW
• the S7NetCom PLC driver
• the HSE Logger
• the HSE Layout Manager