Caraya internal deps

[bienieck]

I would like to ask if anyone on the forum understands why the Caraya add-on from JKI uses such strange files from "_Caraya_internal_deps" folder instead of the original OpenG files? Additionally, why are some displayed in the project as "items in memory" and others as "vi.lib"?

[bienieck]

I’m adding a link to another post on the same topic for reference: https://forums.vipm.io/topic/10300-caraya-internal-deps/

[cordm]

Out of pure speculation, I assume that is an internal dependency of Caraya. I have never used that feature before so I could be completely wrong though.

VIPB internalizes packages that are not explicitly listed as a dependency. That way you will not get into conflicts with other packages that require a different, possibly incompatible version of a package. Since LabVIEW can only have one VI with the same qualified name in memory, some renaming will have to take place.

You can find the documentation when clicking on Help from the Package Dependencies page of VI Package Builder.

[tst]

For the first question, I expect that JKI didn't want Caraya to have dependencies on the OpenG code, probably mainly because they wanted to lock it to a particular version of the OpenG packages which they tested, and you can't have two versions of a package installed in parallel.

For the second, I thought that the Items in Memory section only shows unsaved files, but this is clearly not the case. The LV help has this to say, which I assume gives the answer:

---

When you open a project, the items that a VI calls dynamically do not appear under Dependencies. When you run the callers, the dynamically loaded items appear in the Items in Memory folder under Dependencies

---

I don't know why those specific VIs would be called dynamically, but I haven't looked at the Caraya behavior closely.

[bienieck]

In the first matter, you confirmed my suspicions (although it remains just speculation). In my opinion, this is an ugly workaround that highlights how poorly LabVIEW handles dependency issues—but that's just my opinion, and you may disagree with me.

As for the second matter, I didn’t know that’s how it works, so thank you, tst, for enlightening me.

Overall, looking at what appears in the dependencies while working with the contents of vi.lib gives me a headache, and the bigger the project, the bigger the headache. It doesn't help with managing dependencies effectively.

[raphschru]

---

@bienieck wrote:

In my opinion, this is an ugly workaround that highlights how poorly LabVIEW handles dependency issues

---

Maybe this is not LabVIEW, but rather the person who made the package who configured the package build specification to include and rename everything from OpenG by adding a prefix to the VI names. Adding them to a custom library would be way cleaner though, but this is not possible in the VI Package Builder as far as I know. So this may be more a limitation of VIPM than a LabVIEW problem...