I'm not being critical but... (Re-use) Part 3

[swatts]

Hello Painters of Pictures in the Air,

This article will showcase my notion of dependency management in LabVIEW, it's purely a mental exercise/discussion piece. I find it's very useful in software design to play with prototypes and these can just be pretty pictures, I think this is a very good example of how this works.

This topic began here - 28 - I'm not being critical but... (Re-use) Part 1 and was beefed up here 136 - I'm not being critical but... (Re-use) Part 2.

It also builds on the great work done at CSLUG by Greg Payne - Why you should be using Git submodules and pushed ever forward by James Mac.

I don't want to know the underlying architecture of the repository, I want the IDE to handle this. 

So here's my function palette and you'll notice some extra info. I've stolen the status images from TortoiseSVN. Here you can search for tools and VIs and it will look in a list of known locations. Selected functions can be loaded from these locations as sub-modules, sub-repos or ext-repos and history information shown in the listboxes.

For some use cases you may need to have your dependencies in the environment (I don't like it personally but....)

Here you'll notice that the Delacor toolkit has some local modifications, if this is an improvement you could perhaps push them back to the toolkit maintainer. This would need some management!.

Using  a right-click menu could allow feedback to the toolkit provider and other useful info. Generally you wouldn't be updating to the latest version every time it is available as you would have validated against a particular version. It's nice to know that updates are available tho'.

This proposal would have a radical impact on re-use in LabVIEW, some potential implications are....

1) Pull toolkits on demand into the environment. A minimal install with new functionality being added through toolkits rather than complete upgrades in the environment.

2) Better integration and feedback with toolkit providers, either in NI or outside.

3) Registered, trusted users could push back improvements

4) if the toolkit is correct to a version the project could link to the sub-module rather than import the code. This would make project repositories lighter.

5) Doesn't change LabVIEWs work-flow in any great way, still dropping functions from a palette.

And that's all I have for the mo'

Lots of love

Steve