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

[cbutcher]

This link (Assembling a Relative File Package) describes the creation of Relative File packages, which could be quite convenient for CI/CD systems building into odd directories for dependency installation.

However, the default value for the "--install-root=<directory>" flag for nipkg.exe (if I'm understanding correctly) is given on that page as "C:\Program Files\National Instruments\NI Package Manager\Installed\"

Is it possible to specify at build time a default directory to install to, in the case that "nipkg.exe install mypackage" is called without a "--install-root" flag?

I assume this would also be the behaviour used by the GUI when installing using NIPM?

[CL_eisenwr]

I am pretty sure the Relative File Packages are not currently supported by the GUI. I think this was maybe going to be NI's way to allow one package to be installed in any version of LabVIEW like VIPM. However, it seems like they have left VIPM to fill that role.

You may want to look into JKI's Project Dragon

[cbutcher]

That's a shame, but if true (and no plans to change) then I guess it's just a matter of making the build system file directories match the deployment file system - not a big deal, just would have been nice (especially given PPLs' obsession with relative paths but relative indifference to absolute paths...)

[cbutcher]

It's not what I was looking for, but today I found (whilst searching for yet another thing) that the nipkg config contains a key titled "nipkg.plugin.relative-file.default-install-root", which takes a path.

So on the system where the packages are installed, it is possible to configure the default installation directory. I still didn't find a way to set this on the package, but it's something.

[bienieck]

If NIPM really allows setting custom installation paths and also supports adding custom feeds, for example, from GitHub or GitLab, then in my humble opinion, JKI VIPM and JKI Dragon can be safely considered obsolete. This would allow packages that typically end up in the global vi.lib to be placed in a project-specific folder instead. Maybe NI has finally matured, because what I'm seeing looks like the first real step toward truly isolated environments (unlike what Dragon was pretending to be). The only major issue left would probably be the lack of separation for NI drivers in NIPM.

[SteenSchmidt]

---

@bienieck wrote:

If NIPM really allows setting custom installation paths and also supports adding custom feeds, for example, from GitHub or GitLab, then in my humble opinion, JKI VIPM and JKI Dragon can be safely considered obsolete.

---

Not at all. Git-whatever has no knowledge of the LabVIEW dev environment, so can't set any palettes, tools, help, probes, utilities, IDE hooks etc. VIPM is the only tool that can extend the LabVIEW IDE.

[bienieck]

I'm not referring to IDE extensions, but rather to effective management of project dependencies. IDE extensions are largely tied to developer preferences, and typically, there’s only one developer per PC. However, that developer might be working on dozens of projects from various clients and over different time periods. VIPM doesn’t address this issue. Dragon attempts to tackle it but with little success.

[SteenSchmidt]

In all cases it’s invalid to deem Git a replacement for VIPM, when Git does not extend the IDE at all. That’s one thing.

A separate issue is project dependencies. But what is meant by project dependencies? “Project” in this case is source code and source/build chain configuration. There are primarily two categories of project dependencies then:

1) Reuse libraries, which is source code yourself or third parties have made available to help you get faster to your application’s completion as a developer. These reuse libraries aren’t developer preferences, but choices that go into your application because you want to be done quicker or end up with a more reliable application. Such reuse libraries come with a public API (palettes etc.) and utilities (tools, help etc.) that extends the IDE to allow the developer to use them.

2) Shared runtime components, which are software components that your application finds at the same location on your development machine as in the runtime environment. We use PPLs for that, installed into Program Files or other suitable location with NIPM (could have been a different installer). As you develop your application it’s practical to have a developer front-end (public API available through the LabVIEW palettes) to ease availability and improve discoverability of each PPL’s functions. We make this developer front-end as a VI Package to let VIPM do its job extending the IDE for the developer. At runtime the built application only depends on the shared runtime component (PPL), not on the IDE front-end (VI Package).

Both change with the project, but Git can’t help with that, since Git can’t install IDE extensions nor shared runtime components (PPLs). Other tools must provide this per-project environment switchover. Tools that knows the IDE and can run shared component installers/uninstallers.

[bienieck]

First of all, I meant replacing VIPM with NIPM, not Git (even though Git could work pretty well, in my opinion).

Secondly, every dependency introduces one problem: versioning. So it doesn't matter whether it falls into your first or second category (and it doesn’t matter how you categorize it). If it’s a project dependency, you need a way to keep it tied to a specific version. It can't be global, like vi.lib, because this approach doesn’t allow for multiple versions to coexist. As I mentioned, you might want to have multiple versions on your PC to switch between projects with different dependencies.

IDE extensions can also be released via NIPM quite effectively (e.g., see MGI Solution Explorer).

[SteenSchmidt]

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.

Saying that NIPM can install IDE extensions is like stating you’ll just do all the IDE integration manually instead of letting the package manager do the work for you. NIPM isn’t designed for installing into LabVIEW, it’s designed to install to a predetermined fixed path and any post install actions must be done by code you have built to ship with the package; NIPM can’t mass compile, it can’t let the user choose LabVIEW version to install to at install time (symbolic paths), it can’t modify palette files, it doesn’t know any tool location or IDE extension point. You can do all of that yourself with post install actions, but replacing automatic and free functionality with manual scripting maintained by you is hardly a replacement.