As a developer looking to contribute, I would like to be able to set up a development machine quickly and easily

[stagg54]

Many open-source projects are written in older versions of LabVIEW to maintain backwards compatibility. For example, Caraya is written in LabVIEW 2013 and DQMH is written in LabVIEW 2014. Often these projects depend on a variety of other libraries as well like OpenG.

This presents a problem in that if I want to work on one of these projects I need to install all these things which i may not typically have installed. It would be nice if there was a way to quickly and easily set up a machine with the correct dependencies. It would be nice to have one file and just click on it or run it and poof a few minutes later you are ready to go. Some things I've looked at that do something similar are Vagrant or Docker (probably more Vagrant since Docker doesn't do GUI stuff).

Perhaps we also need something like a .vipc file, but more generic. Right now though vipcs only work for VIPM packages. We need something that can handle the other package styles and/or LabVIEW and drivers (which for newer versions at least NIPM should suffice).

A tool like this would also be valuable for setting up CI pipelines so it should probably be something you could run from the CLI. In that case there may be 2 seperate cases. For CI you don't need a GUI so Docker would work fine (and as a bonus is very lightweight), whereas for development something like Vagrant (with fullon virtual machines with GUIs) would be more appropriate. I'm not saying those are the specific technologies that we should use, but something similar in functionality.

[JamesMc86]

Ditto on docker - super useful for spinning up a test environment. On other backend projects I've worked on you can set up a docker compose which spins up DB and backend for testing

[j-medland]

VSCode supports connecting to containers so once we have a docker environment to run the backend, a small VScode configuration file will enable you to build/ start a docker container and then develop in it. You can even specify container-specific VSCode extensions.

[chrisb2244]

I kind've get the impression that you're (John, Sam) talking about different things?

VSCode does indeed support connecting to containers (which is great), but that doesn't help with the LabVIEW development environment, which would seem to be the topic of this issue/user story. I'd guess that John, you meant the website could be developed/tested using VSCode in Docker?

I suspect the confusion comes from the placement of "GCentral user stories" in the issue tracker for the GCentral website, but that's neither here nor there...

I'm a big fan of the idea of using Docker to build stuff with LabVIEW, but I don't think (at least in the for me foreseeable future, without any inside knowledge of LabVIEW roadmaps etc) that developing in Docker will be practical/possible.

I feel like the idea proposed by Sam, as I understand it, would require the developer of some package being hosted/indexed/referenced by GCentral to provide a Dockerfile (and/or a Docker repository name/link/whatever) for a test/CI machine, and/or a Vagrant file (I have no idea what that is, so if it isn't a thing, forgive me) to describe a virtual machine config. Perhaps the "Project Dragon" being mentioned by JKI recently would help with the latter case? (can't remember the link, can't find it yet).

[JamesMc86]

Yep - I may have kicked off the confusion there. I was thinking about working on the website here, not on LabVIEW. Or Sams comment may pre-date the move off LabVIEW to web technologies

[stagg54]

I guess when I said developer, I meant developer of LabVIEW code, not web developer. Maybe that wasn't clear.

[stagg54]

So to answer your question Christian, Vagrant is for managing VMs. It has a repository system like Docker. So you would have a file similar to a docker compose file. It specifies which base VM to use and a provisioning script to run inside it. You put all that inside your SCC repo.

Then you could check out the repo and just type in Vagrant up and it will pull down the base VM, spin it up and run the provisioning script. Because the script is version controlled, everyone is using the same dev environment.

I could envision having base VMs for each version of LabVIEW and then your script would install all the external drivers and VIPM packages, etc.

[j-medland]

Thanks for clearing things up everyone.

Yes @chrisb2244, my comment was related to having an easy to spinup docker build file for website backend development and testing. I guess that might belong in a seperate issue.

Once the setup instructions for the website backend are up on the wiki I guess I could try creating a dockerfile for it.

[stagg54]

@j-medland sounds like a perfect use case for Docker.