Sign Up
VIPM › Posts › Question about dependency on MGI actor libraries

suggestion

Question about dependency on MGI actor libraries

Suggestion shared 3 years, 6 months ago by Jim Kring
Related Packages: QSI Property Browser
   

Details

The QSI Property Browser looks really cool! Nice job. I noticed it has a dependency on the MGI Panel Manager and/or MGI Monitored Actor. That's find, of course.

Yet, I sort of feel IDE tools shouldn't (for the sake of end users) depend on other libraries that might be used in actual projects. So, these dependencies should, instead, be internalized and built into the distributable package.

Note: VI Package Builder allows the package developer to remove dependencies and thus build those dependency package's VIs into the distributable package.

In practice, I'm not sure how well this would work for the QSI Property Browser -- it would increase the size of your distributable package, at least a little bit. But, it would result in a package with no dependencies imposed on end users.

I'm curious if you've had experience trying this. Thanks again!

-Jim

Comments

Quentin Alldredge Jim, Good call. I probably should remove the dependency for Panel Manager. It was used just for the pop-ups that edit property values. It’s overkill but helps to get the placement right. I’ll work on removing it. I have used VIPM’s built-in renaming and library management for namespacing before. It could be used in this case but probably better just to remove the dependency. --Q
  1
 •  Reply • 3 years
Jim Kring Sounds good :)
  1
 •  Reply • 3 years
Quentin Alldredge This has been fixed in the most recent version.
  1
 •  Reply • 3 years
Steen Schmidt I'm curious as for the reasoning behind not depending on other packages in this case. Any tool for the development environment could benefit from the reuse of other packages. Is the concern because of QSI Property Browser then imposing a requirement of a certain version of the dependent package on the user? We develop packages with compatible main version that can be installed side by side ('String v1' and 'String v2' can both be installed side by side and up/downgraded within that major version independently). Thus, if we had an IDE tool that uses String v1.1.3 for instance, the user is free to upgrade that to String v1.5.0 and our IDE tool would still be happy. They could also install String v2.0.0 if they needed it, without being bothered by our tools' requirement for String v1. Or is it another concern, that an IDE tool has any external dependencies at all? We find it does not pose any limitations, while its a lot of work to suck 4-8 dependency packages into the source for a tool (that's the opposite of having independent development branches for independent packages).
  1
 •  Reply • 3 years
Steen Schmidt I should add that from my example all 'String v1' are compatible, and all 'String v2' are compatible. Any breaking change will rev the major version. Feature additions will only rev the minor version number, and patches will rev the patch (third) number. If you use a feature introduced someplace up the version line (say, in version 1.2.0), then your application will be compatible with major version 1 from v1.2.0 and newer.
  1
 •  Reply • 3 years
Quentin Alldredge Steen, It's not that packages shouldn't have dependencies on other packages. In fact, we should be building off of each other's code to make more useful tools. In this case, however, the Property Browser is an IDE add-on tool. It was using the Panel Actors from MGI's Panel Manager. If I left the dependency as it was, it would lock the Panel Actor class while the browser was running. Because of inheritance, this would lock all Actor classes in the project. One way around this would be to build a copy of the Actor Framework and MGI's Panel Manager into a separate library used by the Property Browser. This would remove the dependency on the development versions but would make the package a lot bigger and the install take longer. The other way around it is just to remove the dependency. Because I wasn't using much of the features of Panel Manager, this is what I chose to do.
  1
 •  Reply • 3 years
Steen Schmidt I understand. It would have been the same if you were using NI AF for instance, the nature of LabVIEW classes. You could've been forced to keep the dependency though, good you were able to move around it with not much hassle. Even though we should depend on stuff when necessary, the other responsibility is even more true: Don't depend on stuff you don't need to :-) Thanks for taking the time to clearify Quentin.
  1
 •  Reply • 3 years

Please sign in to leave a comment.