90 create a vipc that has fewer dependencies

[svelderrainruiz]

No description provided.

[j-medland]

@svelderrainruiz - Can you expand on why you have ended up with these as dependencies for the runner?

1. I haven't used the SLL Toolkit but I think it is more IDE focussed - are you using some of it for git integration?
2. You have OpenG Zip but the zip used in the tooling is the zip functionality provided by LabVIEW (unless I have missed something in Tooling/support)
3. Whilst Replace Caraya with LUnit #128 is on the radar, I imagine we still need Caraya as part of the tooling?

[crossrulz]

@svelderrainruiz
3. Whilst Replace Caraya with LUnit #128 is on the radar, I imagine we still need Caraya as part of the tooling?

I am actively working on the unit tests that are in the project. I plan to have a PR submitted later this week.

[svelderrainruiz]

@svelderrainruiz
3. Whilst Replace Caraya with LUnit #128 is on the radar, I imagine we still need Caraya as part of the tooling?

I am actively working on the unit tests that are in the project. I plan to have a PR submitted later this week.

Thank you for the update. Once you are done, ill make another Github Issue for the block of work to update my powershell process to use LUnit instead of Caraya.

By then we will have a benchmark using Caraya, and i will be able to produce one for LUnit to discuss the improvements on first time setup time. This should be interesting.

[crossrulz]

1. Is there going to be a separate vipc for developers? I didn't see one in the branch.
2. I would like to see a document justifying each dependency. In most cases, a simple sentence would be enough. Something in the wiki would be good enough to me.

[JayKayAce]

Regarding @crossrulz point 2 I would argue we should have the documentation in the code repo as a text file. It is something that changes with the code and will need to be managed through PRs so having it in the code makes more sense to me.
I do agree that we should have the argumenation for each package and what system it belongs to (development environment, testing, pipelines etc)

[svelderrainruiz]

1. Is there going to be a separate vipc for developers? I didn't see one in the branch.

Yes, but that will be on a separate PR, this PR is just to slim down the dependencies for the runner. This new set of dependencies took me 50 minutes to install on a a clean system with nothing but LabVIEW 32 and 64 bits installed.

2. I would like to see a document justifying each dependency. In most cases, a simple sentence would be enough. Something in the wiki would be good enough to me.

Understood, ill produce that.

[svelderrainruiz]

3. Whilst Replace Caraya with LUnit #128 is on the radar, I imagine we still need Caraya as part of the tooling?

@j-medland you may have a system that had some of the components from the VIPC already installed, see below a screenshot of a system that had no dependencies installed.

[crossrulz]

Regarding @crossrulz point 2 I would argue we should have the documentation in the code repo as a text file.

I would probably do a markdown so you can have some formatting.

[svelderrainruiz]

1. Is there going to be a separate vipc for developers? I didn't see one in the branch.

Developers use this new VIPC, it now takes 5 minutes to install. Runner also uses this same VIPC, although i will separate into a separate VIPC if i ever need to expand to more dependencies on the runner.

2. I would like to see a document justifying each dependency. In most cases, a simple sentence would be enough. Something in the wiki would be good enough to me.

The dependencies that are being added are there because of the VI packages that my CI tooling uses. Non of these dependencies are being added to the icon editor itself, only to the VIs used by my powershell scripts. I will add a section on the wiki (automation) that mentions dependencies used for CI/CD tooling.

I added a video on how i use the scripts from this PR as well with the fewer dependencies this PR has, and it takes no longer than 10 minutes to install dependencies for both 32 and 64 bit labview.

https://github.com/ni/labview-icon-editor/wiki/Contributors-Guide#contributionprocess

[svelderrainruiz]

Regarding @crossrulz point 2 I would argue we should have the documentation in the code repo as a text file. It is something that changes with the code and will need to be managed through PRs so having it in the code makes more sense to me.

A change to the readme.md is the right spot. I'd say we approve this PR, since it is specific for a VIPC with fewer dependencies.