SCC & Libraries

[MartinMcD]

I'm wondering how people handle dependent custom libraries with source control please. In each case I'm assuming that each library has its own repository (in my case Git) for the development of the library itself, and each project then has it's own separate repo.

 

Here are a couple of options;

1.  Take a copy of each library the project depends on and check it in to the project repository. Causes duplication but all the custom libraries needed for the build are then in one repo, with the right version.

2.  Install the custom libraries to vi.lib/user.lib. There is less duplication but if someone checks out a project they now need to know to check out the dependent libraries. Plus, if different projects on the same machine depend on differnent revisions of the library it becomes more fiddly.

 

Martin

 

[JKSH]

I'm wondering how people handle dependent custom libraries with source control please. In each case I'm assuming that each library has its own repository (in my case Git) for the development of the library itself, and each project then has it's own separate repo.

 

Yep, one repo per library sounds good.

 

 

1.  Take a copy of each library the project depends on and check it in to the project repository. Causes duplication but all the custom libraries needed for the build are then in one repo, with the right version.

 

This is a valid solution. It's called "bundled libraries". It works for tiny libraries, where creating release packages (described below) might be an overkill.

 

(I personally don't like bundled libraries because the duplication can make things messy in the long run, but it works)

 

 

2.  Install the custom libraries to vi.lib/user.lib. There is less duplication but if someone checks out a project they now need to know to check out the dependent libraries.

 

user.lib was designed precisely for this purpose.

 

The fact that the project devs "need to know to check out the dependent libraries" should not be considered a disadvantage. After all, a project's dependencies should be part of the project documentation.

 

However, the project devs should not check out the library. Instead, they should install the library -- install a stable released version, which has been nicely packaged by the library's developers. See the VI Package Manager: http://jki.net/vipm

 

 

Plus, if different projects on the same machine depend on differnent revisions of the library it becomes more fiddly.

 

Again, I would not make individual revisions accessible. Project devs should only be allowed to choose from the (small) set of stable releases.

 

Furthermore, a mature library should ideally have a stable Application Programming Interface (API). Newer versions should aim to avoid changes that break compatibility with older versions. This way, you don't need to worry about juggling multiple versions -- just install the latest stable version.

 

Exceptions to the "minimize compatibility breaks" rule are:

• When the library is in its infancy: It's ok to play around with the API at the start, to figure out the best design. However, it's probably risky for projects to rely on an immature library anyway. (If the library is that new and it's under your control, you could develop the library as part of your project first. Then, when it matures, split it off into its own repo as a standalone library.)
• When the library has evolved to a point where it needs to free itself from the shackles of old, deprecated functions in order to progress further, or when the burden of maintaining the old functions becomes too great. This should not be a regular occurrence (once every few years, perhaps?)

Edited October 20, 2015 by JKSH

[ak_nz]

We use VI Package Manager for this (vip files) and then deploy a single VI Package Configuration file (vipc) for the actual project that contains the correct version of the package dependencies. This way a developer can open the source and deploy the correct version of the packages.

[eberaud]

Fabiola De La Cueva made a great presentation about this at NIWeek: https://decibel.ni.com/content/docs/DOC-43414

[odoylerules]

I've been thinking about this issue a lot lately and having recently been writing code in Nodejs, I've been considering writing a labview tool that mirrors some of the functionality of the NPM way of handing Nodejs dependencies. 

 

Unfortunately there are pro's and con's to both of the solutions your outline.  I personally would avoid #1 at all cost.  Checking in re-use code to your project repo is just asking for pain down the road.  If you pursue this route, then i would recommend looking into Git Submodules.  However, even those are pain to use but are probably a better route then checking code directly into the project.  

 

As far as #2 goes, this is one of my biggest issues with labview.  It would be so nice if you could have the functionality of the user.lib folder but have it associated within the project folder or on a project by project basis.  If you go the user.lib route, or use the vipc route, you are forcing the programmer to only work on essentially one project at a time.  It has always felt so heavy to me to have to modify the labview program directory to update re-use libraries. However, if your team is heavy into using the pallets, this is the only way that i know of, to get pallets for your libraries working in labview.  This is also pretty much the standard way of doing things currently.  This is probably the better route to go for the time being.  A nice future labview feature to have would be to load pallets out of the project instead of the user.lib  

 

 

Anyway, the approach i'm considering is similar to NPM, why mess with something that works great.  Each project would have a file associated, similar to package.json, that would contain links to the Git repositories that hold your dependencies for the project.  These dependencies would then be installed into the project folder under a single "dependency" sub folder that you would ignore in your .gitignore.  Each re-use library would have its own subfolder within this dependency folder.  

 

The benefits of this system would by that you could then only check in your "dependency" file to your repo.  The user would then "install" these dependencies after they checkout the main project repo.  This process would involve running the tool which would clone the individual library repositories into this "dependency subfolder".  The file location relative to the project file should always be constant so you shouldn't have to worry about linking issues.  In addition, it gives you the ability to keep all of your re-use libraries in separate repositories.  If someone updates a re-use library at a later time, all you have to do it pull down the latest version off of that libraries repository.  It also allows you to have different versions of re-use libraries associated with different projects at the same time.  

 

The main downside i see is that you would lose pallet functionality for these libraries.  I am a big quick drop user, so this doesn't affect me, but could be an issue for others.  Also, this solution probably only works for GIT based source control.  I've used SVN before but i'm not as familiar with it.  There may be other downsides i'm missing i would like to hear about.  

 

I may start a new thread and if i get something working i'll probably look for feedback from the community.  

[ShaunR]

My tuppence.

 

None work great. This comes up at least once a year and always ends the same.

 

SVN externals work OK. (My preference)

Git submodules work, sort of. (Git is too complicated for me).

Checkout in a single directory tree so LV uses relative paths to find sub VIs.

 

The enemy is linking and re-linking which has never been resolved but .is better than it used to be. Resign yourself to just using text based SCC as binary backup system that you can quickly do a restore or branch and life is good.

 

LabVIEW has always needed its own SCC system but NI have little interest in providing one. We cope at best but usually suffer.

Edited October 21, 2015 by ShaunR

[odoylerules]

My tuppence.

 

None work great. This comes up at least once a year and always ends the same.

 

SVN externals work OK. (My preference)

Git submodules work, sort of. (Git is too complicated for me).

Checkout in a single directory tree so LV uses relative paths to find sub VIs.

 

The enemy is linking and re-linking which has never been resolved but .is better than it used to be. Resign yourself to just using text based SCC as binary backup system that you can quickly do a restore or branch and life is good.

 

LabVIEW has always needed its own SCC system but NI have little interest in providing one. We cope at best but usually suffer.

 

I've been using other languages too much recently.  I had totally forgotten about this thread and the general Labview name spacing issues.  My dream of project dependencies solely within the project directly may be a dead one until NI changes some things.  Even Git Submodules may not be a good solution b/c of the library linking issues highlighted in that thread.