User Tools

Site Tools


code:common:dependency-structure

12 Dependency Structure

How do we maintain dependencies in general?

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.

How do we use HSE reuse libraries in a project?

Seeing as LabVIEW is not very flexible in terms of linking to dependencies, and as VI Package Manager is the de facto tool in the community, we maintain all of our reuse code and open source projects as VI packages (.vip) which get installed into vi.lib.

We use our own Release Automation Tools for automatically creating releases.

How do we facilitate git submodules?

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.

Source Code vs. Packages

For some packing mechanisms, it will not be 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.

And what about Package Managers?

We build VI packages for generic and stable reuse libraries, as VIPM is the de-facto standard way of working for most of the community.

Examples for generic open-source projects with VIPM support are

code/common/dependency-structure.txt · Last modified: 2024/08/19 22:52 by joerg.hampel