How should I make my projects redistributable?

[DavidFCannock]

I've worked with LabVIEW for about a year and one thing I've not found any clear documentation or guidance on is how to make projects redistributable so that I can easily build more complex projects on top of them. I've found that the process is a lot simpler in other languages like Java for instance - Java projects can be compiled into JAR files, pushed to Maven repositories and you can declaratively specify dependencies of a project within a Maven or Gradle build script while pointing to these repositories. There is a lot of clear documentation surrounding this process.

My approach up until now has been to produce packed library versions of all my projects. Then if I have some project "C" that depends on code within projects "A" and "B", I create a "lib" directory under the Project C root directory and copy packed library versions of projects A and B into it. I then specify that lib folder as an auto-populating folder within Project C - if I find that my project needs to depend on reuseable code that I've written in some other project, I can just drop the corresponding packed library into that folder.

The main advantages of this approach are that:

• Code is distributed in a precompiled form, so it's immutable and loads faster.
• All dependencies of a project are contained under its root directory so it's easy to move the root folder around. It's also easy to version a project's code (in e.g. Git) along with all its dependencies and collaborate with colleagues.

However, there are limitations:

• When a new version of a project is released, it needs to be rebuilt as a packed library and then that packed library needs to be copied in the "lib" folder of *every* project that depends upon it.
• The code within the projects cannot be accessed via the palette menu.

Recently I discovered that it's possible to produce custom palettes for packed project libraries, place the packed libraries in user.lib and then have LabVIEW use those palettes. This, along with the limitations of my current approach, has prompted me to try an alternative method of distributing code which is to just put all packed libraries of my project that are intended for reuse under "user.lib/<My Company>", which is also versioned and shared among colleagues. This means that I can have all my projects depend upon code located in one location and I only ever need to publish new packed libraries to one location. It also makes it possible to access my code through LabVIEW palette menus similar to how I'd use NI's own VIs.

However, I'm currently having trouble since this approach would involve relocating all my dependencies from local "lib" folders under project root directories to the global "user.lib", and this process can't seem to be done incrementally; if I try to say "find dependencies A, B and C under a local "lib" folder but D and E (which might in turn depend on A, B or C) under 'user.lib' ", I end up with serious project conflicts and errors. The image below shows where I've deleted a dependency ("ActorFramework.lvlibp") from the local "lib" directory of a project to force it to depend on the copy under "user.lib" instead.



It seems like once I've chosen a method of distribution, I'd need to fully commit to it and go bottom-up through each of my projects and make them use this new approach. Because of this it's important that I make the right choice before I start.

I'm also concerned about using this new method of distribution. How easy will it be to distribute my code with someone who doesn't have their own copy of our company's "user.lib"? Projects will no longer be keeping all dependent code under their root directory.

For the record, I've also tried playing around with VIPM but it doesn't seem to work with packed libraries.

In short, I'm wondering what's the best way to make it so that I can redistribute my projects easily.

[Florian.Ludwig]

While I don't have a solution I have two things to say:

1. Thanks for writing this detailed description
2. I'd really like someone more knowledgeanle tahn me to chime in, possibly even someone from NI.

[DavidFCannock]

---

@Florian.Ludwig wrote:

While I don't have a solution I have two things to say:

1. Thanks for writing this detailed description
2. I'd really like someone more knowledgeanle tahn me to chime in, possibly even someone from NI.

---

I'm in contact with National Instruments about this issue and I'm linking this thread to them.

[Bob_Schor]

I have a little experience with VIPM, and think it may well be something that you could consider.  It does manage integrating a "package" into LabVIEW, putting VIs into Palettes for easy incorporation into developing code.  A single package developed in, say, LabVIEW 2012, can be designated as suitable for 2012, 2013, 2014, and 2015, and if installed (using VIPM) in those later systems, will be separately installed (and compiled) for each of those versions.

I'm not certain if packed libraries are supported by VIPM, though VIPM 14.0 says it will accept them as input.  However, the VI Package may have similar advantages to a packed library -- it should certainly simplify re-distribution.

I hesitate to ask, but I think you could do a real service for the LabVIEW Community by trying VIPM (even without Packed Libraries) and letting us know how it works in the context of what you want to do.  I realize this is "not a sure thing" -- you may spend valuable time and decide that it will not work for you, but the knowledge and experience you could provide to the rest of us would be invaluable!

Bob Schor

[DavidFCannock]

---

@Bob_Schor wrote:

I have a little experience with VIPM, and think it may well be something that you could consider.  It does manage integrating a "package" into LabVIEW, putting VIs into Palettes for easy incorporation into developing code.  A single package developed in, say, LabVIEW 2012, can be designated as suitable for 2012, 2013, 2014, and 2015, and if installed (using VIPM) in those later systems, will be separately installed (and compiled) for each of those versions.

I'm not certain if packed libraries are supported by VIPM, though VIPM 14.0 says it will accept them as input.  However, the VI Package may have similar advantages to a packed library -- it should certainly simplify re-distribution.

I hesitate to ask, but I think you could do a real service for the LabVIEW Community by trying VIPM (even without Packed Libraries) and letting us know how it works in the context of what you want to do.  I realize this is "not a sure thing" -- you may spend valuable time and decide that it will not work for you, but the knowledge and experience you could provide to the rest of us would be invaluable!

Bob Schor

---

I've tried VIPM in the past as well as more recently. You're right that the VIPM 14.0 release notes mention something about a bug being corrected involving including PPLs in packages. However, I've had no luck in building packages where I specify a packed library as the source (VIPM complains about not finding any valid source files). In the past I also found that VIPM would throw errors if I tried to package any project that contained PPL dependencies under the project root directory (although I haven't tried that more recently).

I'm in contact with NI about their recommended approach and if necessary, I might have to go through the several thousand VIs I've written and get them to point to lvlib versions of their dependencies instead of lvlibps in order to use the VIPM approach. That'll probably be a bit painful so I'm hoping to get a really clear idea of the right approach first.

[Bob_Schor]

I would also recommend getting in contact with JKI (jki.net), the people responsible for VIPM.  I'm sure they will be able (and willing) to help you, at least to the extent of giving you Good Advice.

Bob Schor

[DavidFCannock]

After being in contact with JKI, NI and looking at related forum posts/Youtube videos, our team has started exploring a new approach to code reuse.

My colleague and I have each started a 30-day free trial of VIPM Pro. We've configured our office's server to act as a VIPM package repository and set our VIPM instances to point to it.

We imagine our workflow to be like this:

1. When starting a project, create a Git repository on the Atlassian Stash service running on the office server.
2. Clone the repository on my local machine, which creates the project root folder.
3. Create a blank project within the project root folder and save it as <project>.lvproj.
4. Create and save a library in the project as <project>.lvlib.
5. Continue coding up until the first release.
6. Create a VIPB specification for the project. Add library prefix, ensure library is locked, etc.
7. Create and install first release package from VIPB.
8. Test out the project locally from the consumer's perspective.
9. If all goes well, publish the package to our company's VI package repository.
10. In "higher-level" projects, repeat a similar process and consume dependencies from the lower-level packages installed under vi.lib. In the case of VIs, they should be locatable within a palette file. In the case of inheriting from a class included in a lower-level project, the class (or its containing library) should be added to the project ("My Computer -> Add... -> File...).
11. Specify all dependencies within a VIPC for the higher-level projects.

I've tested out this approach in the attached zip file to address the practical example mentioned in this thread.

[pawhan11]

Interesting discussion,

I am also thinking about redistribution with current project.

My idea so far, is to assume fixed location for all my libraries for example C:\ProgramData\LVAPI\api1\api1.lblibp

when code will reside in a structure like C:\ProgramData\LVAPI_Dev\api1\api1.lvproj

If another application requires library it is linked directly from that location. When I build all and select exclude dependent packed project libraries this works fine.

The problem is that I can not have multiple versions of the same library on one machine. If someone wants to use my code he must follow exactly the same location of LV projects and packed libraries or it will break.

As for distribution and depoendency management between packages I will look into NIPM and give it a try.  

It would be nice to hear how NI or other company that handles big software in LV handles distribution.