Is it possible to set a default path for Relative File NIPKGs?

[bienieck]

---

@SteenSchmidt wrote:

We have multiple versions of the same reuse library installed simultaneously in vi.lib, no problem. Same with multiple versions of the same shared component (PPL), no problem.

---

How?

[bienieck]

Let me explain in more detail what I mean, what I dislike about the current solution, and why I look at NIPM with hope.

The main issue I see is the existence of a global vi.lib and the inability to open multiple projects simultaneously when they rely on different versions of the same dependencies. In other words, there is no meaningful equivalent in LabVIEW to Python’s virtual environments or even the environments available in TestStand.

Steen, you claim that this is achievable and that you are using such a setup yourself. Please share your knowledge on how to achieve this with VIPM because I have no idea how to implement it. Specifically, I am unsure how to do this in a native way.

On the other hand, if NIPM allows for custom feeds, it should theoretically be possible to configure it to point to GitHub Releases, where both APIs and tools can be stored. This might even allow me to distribute source code in this manner. What’s particularly interesting here is the ability to specify the root directory of a project during installation (via CLI). This would allow me to add specific versions of dependencies directly to a project’s working directory. With appropriate path organization, this could lead to a very modular and isolated package management solution that doesn’t affect vi.lib. Of course, all this assumes that it works the way I imagine. Additionally, it would be helpful if the items I currently install via VIPM into the LabVIEW folder could be installed in a new way (e.g., wherever I specify).

Steen, you made a valid point about IDE extensions. However, thanks to your comment, I can only expand the list of things I dislike. Specifically, I cannot have IDE extensions assigned per project (though Dragon could potentially provide such a solution, and in this specific context, its functionality would be satisfactory for me).

Regarding project dependencies on IDE extensions—if an API is entirely dependent on tools distributed with it, I believe this is a bad design choice (too tightly coupled). Newer versions of tooling should allow me to continue using older APIs. I should be able to install the latest support while still relying on an older API. If that’s not possible, it means someone didn’t design the system correctly IMHO.

I’m not entirely sure what I’ll be able to achieve with the current NIPM, but I’ll try to create something resembling a true virtual environment based on GitHub Releases, functioning as an artifact repository.

[SteenSchmidt]

Regarding versioning of shared components and reuse libraries:

We employ semantic versioning, where major versions are distinct and can be side-by-side installable. You decide as a developer if you want to use v1 or v4 of a product, if you decide for part of the project to use v2, you are not forced to also upgrade to v2 for everything else that hitherto used v1. Similarly, if you load a plugin or another kind of external component, that component can easily use v1 of something while other parts of your application uses v5 or whatever. Due to strict adherence to semantic versioning, all minor package versions are internally compatible, so the project isn't sensitive to if v2.0.4 or v2.7.0 is installed. There will be a lowest common denominator of required version, but all your application will function equally well with any of the versions at or above that (within the major version). Our tools handle building of the different namespaced versions automatically (specific source configuration management, library naming, linking, palette adjustments, vipb configurations, appbuilder configurations, install location settings etc.).

On disk it looks like this in vi.lib (PPLs are LV runtime version independent and reside similarly in Program Files and other relevant places):

In VIPM it looks like this:

On the LabVIEW palettes it can look like this (the developer can choose which major version to use for their application/component, and nothing will break if the version updates):

We have a tool that from a single package source configures the building of different outputs into reuse libraries or shared components (different versions, different types, different configurations):

Our main configuration and build tool is called VIP Assistant:

[bienieck]

OK, this looks quite nice. It seems to me that I saw it in action at one of the user group meetings, but later I couldn't find it anywhere. Am I remembering correctly?

Nevertheless, this is not a native solution, and it appears that you still invested time in preparing something that isn't available "out-of-the-box." So essentially, it could have been done just as well based on NIPM, but never mind that.

Is this tool publicly available?

If I have code that uses the Array v2 library and I want to switch to Array v3, how does that work? Do I have to manually change all the calls in the code, or is it somehow replaced automatically? There will be different paths to the VI, so that has to be taken into account, right?

EDIT:

Do you have folders and palettes only for the Major version, or also for Minor and Patch versions?

How can you have multiple versions of IDE extensions? Is it possible for example to have several versions of OpenGDS support tools installed simultaneously?

[SteenSchmidt]

---

@bienieck wrote:

[...]something that isn't available "out-of-the-box." So essentially, it could have been done just as well based on NIPM, but never mind that.

---

Sort of true. We do have custom tools made, and in theory it could be done with NIPM as well. In practice NIPM would require a lot more manual work, since it has no facilities to help you extend the IDE, which VIPB/VIPM does. It's still a lot of work automating it all, so I guess you have a point there.

We are working on publishing this somehow, but it does take a lot of work getting everything sorted out when business gets in the way... We also have some problems with VIPM which JKI isn't particularly quick to solve, so there is that as well...

Changing from vX to vY will currently require manual replacement at the call sites. We rarely replace, we more often see a new version brought into use for newer designs. But replacements do happen, and we have some semi-automatic tools to help us with that. But not quite ready for public consumption yet.

[ShockHouse]

bieneck,

If you haven't seen this, it will probably interest you to see how the LVAddons in LabVIEW 2022+ can be used for virtual environments. Both by reading the comments in the github link, and it also points to links in the comments of people experimenting with it for virtual environments.

https://github.com/ni/labview-icon-editor/discussions/105

It seems like it's the step in the direction you are looking for (vi.lib, project templates, etc... specific to an environment instead of global). There just isn't the infrastructure around it. But with NI moving the Icon Editor to LVAddons, more and more of that infrastructure seems to start being included. Wherein each project could have its own LVAddon that gets pointed to, and you would just need to install things to that location.