Managing Dependencies in SCC – Part 1 – The Problem

It all started two years ago when I watched a presentation in NI Week 2018 from Christian Butcher about Clean Architecture.

This time, I was really attending (not virtually) NI Week ’18 (which, by the way, I am really grateful). Although you can watch videos from the conference later, it is really important to attend these conferences, mainly because when you are there you are really committed to learning and interacting with other developers, instead of being distracted by something in your work or in your home office.

Anyways, getting back to the presentation, a particular statement said by the Presenter was immediately saved in my head, in minute 15, he says to “move modules in separate projects to explicit your dependencies”, and afterward “handle every actor in its own project”, not exactly the right words, but that’s the idea. This is the moment when you say, what?? I have to start doing it.

A change in paradigm

After NI Week I just wanted to get back to my office and start coding (not really). The first thing I started doing was to create projects for each of my libraries/classes. That was a moment where everything became clear, and also disappointing. My modules depended so much on each other.

Then I decided to start to put in practice what I was learning about “Abstract Messages” in Actor Framework (future post on it), and started decoupling my modules. The next step would be to add all these modules in separated repos in the SCC. I still had no idea what I would have to face, but in the middle of this process, a project came up and I had to stop and focus back on coding.

At that time, at least my code was finished with abstract messages and decoupled modules, every module in each project, but everything was still in the same repository, not something that I was comfortable with, mainly thinking in reusability.

Source Code Control Issues

If you don’t you use Source Code Control, what? You don’t? Ok, never too late. Stop everything you’re doing right now and start studying to implement and use it. Not joking, I am serious.

I am currently using Git, for numerous reasons that it is not the subject here, but if you are already using SCC and it is not Git, you may want to change to Git. There are lots of places to start learning, you can try the Git Official Documentation, or in Sam’s blog, (he is writing a series of posts on Git for LabVIEW developers).

So I started creating my projects in Gitlab and uploading each of the modules in its projects. The problem was: how do I assemble them together after that? I had the solution already, I am so a smart guy (being ironic) and had read everything about submodules in Git, and I was confident, it would work flawlessly.

It did not, I turned out that submodules becomes a nightmare when you started dealing with submodules inside submodules, tags that are not applied, modules that are not cloned, a growing number of submodules. Really, it is stressful (leave your comments if you had this issue too). Later I found out a very good presentation from Greg Payne in Gdevcon about how he managed to overcome some of these problems.

Alternatives

Then my concern was to find a solution, so let’s enumerate them and some points that I’ve taken into account. My starting point was the LV Wiki on this matter:

• VIPM – Great option, possibility of integrating third party packages, very popular, but not project scoped, and besides, only the paid option gave the possibility of creating individual configuration files (.vipc) per project. I was not willing to acquire a licence at that time, although my opinion has been changing on that;
• NIPM – Also not project scoped. Very recent, integration with LabVIEW IDE (build specification). Good alternative, mainly for installing apps, but not for source code development and code reuse;
• GPM – very new at the time, and I had a really difficult time using it, in fact I tried twice and aborted. The idea of GPM is perfect, project scoped, possibility of downloading reusable code inside your project. But, I really got disappointed about not getting it to work. And besides, it also did not have private repositories, and the idea of inserting code from my company online would seriously implicate in lots of problems for me;
• Git Submodules – ….

Solution

So, I needed something at the same time very easy to integrate (like GPM), extensible, project scoped, and without the need for creating packages (not my use in fact), but only for code reuse. I kept my research until discussing with my colleague, he pointed me out some features of the Gitlab.

Yes, I took the hard way, I tried to (actually did) develop my own dependency manager (kind of), but this a subject for my second post. This one is becoming too big.

Until there, leave your comments below of how you manage your reusable source code in LabVIEW and any questions you might have about this post.