Support "Development Environments" / "Development Sand Boxes"

[Andi_S]

Similar ideas have already been posted but non of them totally hits what I'm missing.

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version

long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short: I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

[fefepeto_kb]

The idea is good in general, but I think we have a corner case, that is not covered. Ok, this might be the main use-case: hardware related software stack. I think we can all agree that having two projects with different DAQmx drivers is two operating systems. There is just no way that you can swap between the two versions, especially if there is a conflict. The actual reason for this is the files installed under the Windows folder, which will have a similar shared folder alternative under Linux.

If we would disregard the hardware aspect for a second, I think what you are requesting is practically containerizing the development environment. It is usually not managed by the development environment, but might be accessible trough the development environment for a better developer experience.

Back in the day we used separate virtual machines, or separate boot images (partitions with their dedicated OS) on the development PCs or controllers to separate the different software stacks. We did a bit of research and it was the fastest feasible option to maintain multiple software stacks, especially with a lot of hardware dependency. Containers might be better for this use case tough.

[fabric]

If only multiple LV environments were as quick and easy as Python venv's...

[Quiztus2]

related: Enable LabVIEW project to specify VI search path... - NI Community

and yes, we somehting like this.

[GregR]

We do want to better support this workflow but are looking at a different approach. Rather than introducing another concept and requiring a separate copy of files, we want to expand the existing project to be more in control. This has a couple implications.

• Settings that are currently LabVIEW-wide would become project specific. From your examples this covers things like having project specific search paths because those could be set at the project level. Beyond that there could even be banned and/or approved locations in the project that define where a project can load files from.
• The project has control of which "addons" are available. Here addons refers to any API or editor extension that is not part of the core LabVIEW install. Pretty much everything from VIPM qualifies as an addon, as well as any of the optional pieces from the LabVIEW installer or from NI Package Manager. Instead of all projects using whatever is installed, each project could define which addons it wants.
  Starting with LabVIEW 2024 Q1, JKI Dragon is included as an optional component in the LabVIEW installer. It allows each project to declare what dependencies are needed. Currently that can be used to ensure the right dependencies are installed on the machine. We want the project to also use that file and be able to ensure that those are the only addons available.
  
  • A key piece to this support is having addons install into the "LVAddons" directory instead of the LV directory. This keeps each addon isolated so instead of making a separate instr.lib for each project, each project would say which of the LVAddons that contain instr.lib it wants to use.
    This mechanism also allows a single install of an addon to be shared by multiple versions of LV. You would no longer need to reinstall all your addons when you upgrade to a new major LV version.
    This change is also important for security. Currently the LV directory is made writable by anyone (instead of only admins) so that any user can install an addon. This is a security issue being flagged by internal audits at an increasing number of customers because it allows any user to modify files that will impact the behavior for other users. Most addons produced by NI have switched over.

[Quiztus2]

Does opening a VI within a project context affect its stored subVI paths, and are those paths overwritten upon saving the project?

[GregR]

Related to this, no. Anything from an addon should be referenced from other VIs as a symbolic path. For example, a VI in any "vi.lib" will be referenced as "<vilib>:\relative path within vi.lib". The project would control which vi.libs we look for that path in but the path persisted in caller VIs is not impacted.

[Quiztus2]

The flexibility to "ban" paths is then limited to components installed through those platforms, rather than custom project directories authored locally. I am afraid this is not sufficient.

[GregR]

Sorry, my answer was just about the ability to control which addons are available. For references to things in addons, there shouldn't be a problem.

For your own files (everything not in an addon) the answer is different. If implemented the blocking behavior would support any path. For that, there are scenarios where loading the same VI in different projects would result in different paths and the VI wanting to resave depending on which project it is loaded from. There are likely workflow approaches that would avoid that. It depends on the exact scenario but it could include packaging some of your internal libraries as addons or having a copy of the VI for each project. The idea is that this makes it safer to have a VI duplicated between projects because you can have each project exclude the other's directory and know you'll never load the wrong one.

[cy...]

This idea will only work if the LV folder itself is secured; otherwise, it could introduce additional security and integrity risks.

@GregR: How has this vulnerability not been disclosed (with CVE published)? A bad actor could plant binaries, and developers might unknowingly build and deploy compromised solutions.

"Currently the LV directory is made writable by anyone (instead of only admins) so that any user can install an addon. This is a security issue being flagged by internal audits at an increasing number of customers because it allows any user to modify files that will impact the behavior for other users. Most addons produced by NI have switched over."