VIPM Distribution

[corcorpj]

This is a more conceptual issue for discussion on distribution and release. VIPM is the preferred mechanism for community packages; however, the concept for this application is embedding the log facilities on the 'per project' basis - as is standard in nuget, yarn, npm, and other programming contexts.

If VIPM distribution can provide the files to the widest audience, and de-couple monolith dependency in vi.lib - then we explore distribution options and builds that support this model.

Looking for community feedback on this topic, please comment below.

[RobustoSystems]

First, thanks for creating what looks like an extremely useful tool. I haven't had a chance to try it yet, but I aim to do so in the near future.

"VIPM is the preferred mechanism for community packages" - Fully agree. Being able to install through VIPM makes the tool much more accessible. The package could then be included in people's VI Package Configuration (VIPC) files.

"however, the concept for this application is embedding the log facilities on the 'per project' basis" - Can resonate with this concern. The free, open-source Error Manager package I created (https://www.vipm.io/package/robusto_systems_lib_error_manager/) suffers from the exact same concern. It is meant to be a "per-project" add-on. It currently installs into user.lib. The user can then use it as a global dependency from that location, or can manually cut (move) the folder into their repository. This can be painful because the user often needs to manually relink the VIs by opening the Main VI and pressing "Enter" through dozens of LabVIEW load warning dialogues. Once this process is done and the VIs are saved, it doesn't need to be performed again.

I was considering writing a VI that would execute as a VIPM post-installation action that would move the files from user.lib to a user-selectable location. The VI would pop-up a user-facing window that enables the user to select a folder (likely a folder inside a git repository) into which the files should be copied. Alas, I haven't got round to implementing and testing this feature. I'm not sure if it would solve the dependency linking issue, or how well it would work when the package is installed programmatically via the VIPM API or via a VIPC file. Not sure if the post-action window would block the installation of subsequent VIPs that may be part of the same VIPC file (I have not tested this yet).

In short, I don't have a solution at the moment, but just wanted to let you know that there are other packages that suffer from the same concern.

Kind regards,
Petru Tarabuta, Robusto Systems Ltd, UK

[corcorpj]

Hi Petru -

Thanks for the feedback and sharing your experience. Another idea I have in the background is developing a CLI wrapper around the VIPM distributions - that allows for localized operations (eg. npm, yarn, nuget) but for LabVIEW. I was recently shown another JKI tool - https://dragon.vipm.io/features/#toml-file-format . This is a project launch/management framework that tracks and restores dependencies per project; however, it continues to target user.lib.

Ultimately, the reason I am so interested in localizing project dependencies is (especially at that LabVIEW 2024 forward/backward compatibilities are expanded) I work on many different projects and different versions of tools - I often run into issues with monolith dependencies causing conflicts with project - this leads to Virtual Machines per project which adds it's own management headache.

I genuinely think the programming language SDK (LV Community/Pro) needs to be decoupled from 3rd party libraries.