Feedback request on initial draft of LVAddons documentation

[svelderrainruiz]

The LabVIEW R&D team asked me to collaborate with them on an early draft of the LVAddons documentation. I mentioned that it would be important to request for feedback from the community since not having documentation about this has been a major pain point for most of us, and they agreed.

Please comment on this thread on what you would think is useful to elaborate more, but please keep in mind that this is a very early document we are working on, which we are releasing so that we can cover all corners regarding the LVAddons documentation.

LVAddons-Developer-Documentation.md

[oli-wachno]

Thanks for this first draft! Since we are heavily using PPLS I'm especially intrested in the TBD part ;)

[oli-wachno]

Is this document supposed to become part fo the official LabVIEW documentation? Or will the LabVIEW Wiki be the final destination?

IMHO; Since NI is the creator of the LabVIEW Add-Ons Interface, I guess this should stay somewhere in direct access of NI, Especially for maintenance reasons.

[svelderrainruiz]

Is this document supposed to become part fo the official LabVIEW documentation? Or will the LabVIEW Wiki be the final destination?

IMHO; Since NI is the creator of the LabVIEW Add-Ons Interface, I guess this should stay somewhere in direct access of NI, Especially for maintenance reasons.

We intend this document to be on a location that NI can maintain, and we will additionally post it on the LabVIEW wiki to gather additional community input.

[matthiasbaudot]

That's a great start @svelderrainruiz, thanks a lot for doing that!
I'm also particularly interested in the PPL section when it's available.
Everything else seems pretty clear except for the "Per-target LibraryPaths" in the "Location of LVAddons" section, which I don't understand how to use. An example would be helpful.
As a more general comment, examples are likely appreciated everywhere for everything that can be set or customized, so there might be something to improve there IMO.
Another note, regarding the "SupportedBitness" JSON attribute. The documentation doesn't say if it is a String or Numeric datatype. Again, an example would clarify this.
Thank you so much!

[svelderrainruiz]

This is great to hear Matthias, thank you, i am sure Christina will appreciate the kudos! @eyesonvis.

[svelderrainruiz]

Posting this thread from the NI forums for more context on the pain points people are having.

https://forums.ni.com/t5/LabVIEW-Champion-Discussions/Why-you-should-not-upgrade-LabVIEW-Spoiler-LVAddons/td-p/4407374

[jacobson3]

Just so you know, most people won't have access to that forum.

[svelderrainruiz]

correct, this is for internal tracking purposes, i wanted to link all the good feedback we got there to this github issue.

[negentropicdev]

Are there minimum versions of LabVIEW that any of this applies to? e.g. what version of LabVIEW is -pref available back to?

[JayKayAce]

If I remember correctly, @gregr-ni mentioned it to be LV2022 or later.

[joerghampel]

I will out myself as somebody who is not that much into PPLs. Also, we never install more than one LabVIEW version in parallel, so that use case falls away, too.

What I'm curious about is the topic of Symbolic Paths, and what we can do in later versions of LabVIEW with the described feature of providing a list of locations. For example, how about being able to change the order of precedence for resolving paths? If we could make LabVIEW in a user-provided location first, we could potentially implement our own per-project vi.lib...

I understand that these slightly tangential details might not have highest priority in a document focusing on LVAddons - I hope you don't blame me for trying to sneak them in...

[Flydroid]

I think that is what Felipe is doing with his experimental virtual environments:
https://felipekb.com/2024/09/26/enabling-virtual-environments-in-labview/ and https://gitlab.com/felipe_public/lv-venv-tools
Which is super cool!
I think it's a important topic and should be discussed in context with improvements to dependency management that NI (and JKI) has promised.
With VIPM and/or Dragon we have dependency management, but they need to allow to install packages into the custom LVAddons location.