What’s the best way of distributing code to a new dev pc?

[Lewis_G]

Hey all,

I was recently given a job to work on somebody else’s code.  I downloaded the code repository but there were lots of dependencies.

The first dependency was a “Core library” used by my company.  This is a set of useful VIs which is always in the same place on C:\.

Once I got that I still had a load of openG dependencies.   I had to look at what VIs the project was missing/trying to find and then download the right packages from VIPM.

Finally, the code final opens and runs.

My question is; how can we avoid this pain in the future?

When moving to a new development PC, there could be missing packages from VIPM, missing modules/toolkits and missing code repositories.  What’s the best way to keep track of dependencies?

I’m guessing it would be for the developer to include a list of requirements that are needed and then you just have to go and download them all.

Could you make a single package you can install that has all the dependencies?

Any thoughts?

[MarcoMauri]

An option (I don't know if it's the best or not) could be to build a source distribution including all the dependencies.

Regards,

Marco

[Phil_]

When copying things between development machines I often use the 'Duplicate hierarchy to new location' in the Save As menu.

[crossrulz]

Look into VIPC (VI Package Configuration) files for VIPM.  You can include the packages themselves in the config file.  You can then perform a simple "apply configuration".  I would also recommend turning your company's library into a package.

[Lewis_G]

Thanks for the suggestions guys.

I looked more into VIPM Pro and it seems really good.  I downloaded the trial, had a go and then proposed it to the boss as the way forward.

[User002]

---

@Lewis_G wrote:

Thanks for the suggestions guys.

I looked more into VIPM Pro and it seems really good.  I downloaded the trial, had a go and then proposed it to the boss as the way forward.

---

Use GIT or Mercurial instead of a proprietary centralized solution.

Learn how to use GIT together with your collegues. Set up a workshop and start committing, branching, pulling, merging and pushing to each other's computers without some clunky 3'rd party tooling.

It is also very beneficial since it lends itself very well to other software development enviroments, mainly text based, though, whereas VIPM is a LabVIEW only world.

http://git-scm.com/documentation

Br,

/Roger

[SteveChandler]

VIPM is not source control. It is an entirely different animal.

[User002]

---

@SteveChandler wrote:

VIPM is not source control. It is an entirely different animal.

---

Ah, yes, of course. Another advantage for GIT/Mercurial that can act as both. 

Br,

/Roger

[SteveChandler]

GIT and Mercurial do not do VI Package Management. They do not have LabVIEW pallette editors or dependency checking. They do not connect to the tools network and there are no VI Package Configurations.

[User002]

---

@SteveChandler wrote:

GIT and Mercurial do not do VI Package Management. They do not have LabVIEW pallette editors or dependency checking. They do not connect to the tools network and there are no VI Package Configurations.

---

Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.

Less is more.

Br,

/Roger