Plugin Management in Real Studio

We tend to have a lot of plugins installed at any given time. We have the full compliment of Einhugur, most of the Monkeybread (MBS) and a handful of others. However, not all projects need that full complement of plugins and the startup time of Real Studio suffers accordingly even on state of the art iMacs with 8 GB of RAM using SSD drives.

We tend to run 2 or 3 versions of Real Studio at a time because not all projects are on the most current IDE nor on the most up to date plugins. This can mean that we have the possibility of mixing plugin versions across our development staff.

Not every version of Real Studio can run all versions of the plugins. You’ll find this to be true in the 2012 R1 release as RS has changed the plugin API so some plugins may not work and cause the IDE to report errors (I believe there’s a workaround but I can’t find the email that contains that info).

The Real Studio IDE does not contain any information on plugin versions. Einhugur plugins contain some version information (which you can see in the Help -> Plugin References menu in you have any Einhugur plugins installed) but otherwise you’re on your own. I have my own person plugin archive that’s separated out by plugin vendor, plugin, and then by version. After talking with my developers we discovered that we all do it this way.

Is there a better way of managing this mess? One of the projects we purchased from True North Software is RBVersioner which holds some promise in helping manage plugins. I spent a few days working with it discovering how it works and I came to the conclusion that it doesn’t do anything for me. And since I’d like to think I’m an average RB user perhaps others would have similar thoughts. Which, of course, made me hesitate to spend a whole lot more time working on it.

So the question I have for you, my Real Studio friends, is do you think plugin management is an issue with Real Studio? In your ideal world (other than the IDE doing the management), what would your perfect utility for plugin management do?

I would love to see a utility where I can create a project ‘set’ and point it to a version of Real Studio (i.e. 2012 R1, 2011 R4.3, 2010 R5.1, etc) and it would be able to pull the plugin versions I’ve selected for that project. I’d love to be able to save any relevant information about any given plugins (min/max versions of Real Studio, targets supported or not supported, dependency information, vendor, release date, etc) and just tell the utility to install the correct plugin set and restart the correct version of Real Studio and automagically open the associated project. I’d also like a report generated for the set that contains Vendor, plugin name and version number so I can give that to my client when I hand project source code over to them. I’m not asking for much, no?

The first question that came to mind after I wrote down all of these ideas was this a solution really in search of a problem? After all I’ve been doing full-time Real Studio development for over ten years and somehow I’ve managed to get manual plugin management to work so far.

Is plugin management a problem for you? Would you spend $10 on a utility to make this easier?

23 thoughts on “Plugin Management in Real Studio

  1. Bob yes, you would get my 10 dollars ;-). It would be so beneficial to have some control on what is getting loaded at start up and compilation time. Cheers, Jeannot

  2. I would tell every plugin user about your tool 🙂
    Still the solution so far is to keep a set of the plugins needed for a project with the project (in svn) and have an alias point to that plugins when you load the project. You know that the plugins folder from Real Studio can be an alias or a symlink?
    Else you can simply use latest plugins which is normally the best for ours.

  3. This is a case of the tail wagging the dog. This problem really needs to be solved by RS. If RS puts it on their radar, you are probably looking at 2 to 3 year time frame for a solution from them.

    Bob, I would say you are not a typical user in that you are pushing the limits. What I suggest you do is develop out of DMGs per project(s). That way you can precisely control the environment including the IDE and plugins on a per project basis and you can store the DMGs in your favorite version repository. Maybe you could rewrite RBVersioner to create the DMG file. I would check out using aliases to save space in the DMG files.

  4. Our plugin management is terrible. But it is not a simple problem to solve, so we haven’t done so yet.

  5. For each of my projects in RS I have two branches in SVN – one for the code and one for the particular set of plugins that project is using. When I change projects I simply run a BAT-script that updates the source of the project, checks out the plugins needed and deletes the cache directories of RS.

    Didn’t know that the plug-in directory could be an alias. Haven’t tested on Windows but this will surely shorten the project-switching time – Thanks!

    Surely the plug-in handling sucks. But there are so many other things that in Real Studio that need RS’s TLC and I’d say they should put their resources there instead.

  6. Thank you Christian. The hint with the alias is a workaround only but a very helpful one indeed! Never thought about such a simple approach. Thanks again.

  7. Like you Bob, I have multiple versions of RS. Since I started to work in Cocoa, I’ve created a Cocoa only version (which contains only the plugins that I currently need, which are a handful of Christian’s). Where as my Carbon version contains far more MBS, and Einhugur and even some custom plugins that we use.

  8. If the plugins were in the application support folder with an interface in the IDE that let me turn them ‘on’ and ‘off’ for each project then most of my issues would be solved. Particularly if the IDE saved that information in the project file, and it allowed for many versions of the plugins (and obviously making that version information available in the selector interface).

  9. I’m starting to lean towards just axing the RBVersioner project. Sounds like most people have *a* solution even it’s not a great solution.

  10. @Bob Keeney

    Agreed. I was just thinking that it wasn’t the most complicated issue I’ve ever seen. Unless of course they’ve coded themselves into a corner, so to speak.

    I’m unclear what advantage the RB versioner would give me. If you move forward then you’ll have to do some serious marketing. Making a headache a little less painful isn’t an easy sell. I imagine most of us are holding off for a solution that cures our affliction.

  11. Well, one way could be to make the utility the default handler for projects. This way when you double click project in the Finder, it could check if there is a plugins folder in the same folder as the project and change the alias pointing to the plugins folder if needed. Or change back to the general plugins folder. And if needed, restart Real Studio. Than send open event to Real Studio to open the project.

  12. Bob, keep in mind the basic problem that RBVersioner solves in that every plugin vendor out there does versioning of their plugins differently. This makes maintenance a real pain. RBVersioner unifies the all plugins to have the same style version information and thus you can look in one place for version information.

    Before I created RBVersioner I tried to get all the major plugin makers to adopt a single version standard for version information because RS “REALLY” dropped the ball and did nothing. Alas the plugin makers didn’t understand the significance of choosing the path of so many diverging ways or they were hostile to the idea because it would change their development process which they already invented (i.e., a screw you mentality). To this day, versioning plugins is a mess without RBVersioner. Now you have another opportunity here unify the version information by having the plugin makers adopt RBVersioners version information format and incorporate it into their build processes.

    Bob, concerning how you would apply RBVersioner to your specific environment, I don’t think you are thinking creatively enough. For example build in the concept of plugin “sets” that RBVersioner can load in and out at the click of a button. But again, there are some basic functionalities that RS must tackle to really make this part of the environment to shine. One thing they could do today is make the RBVersioner version format the standard and then provide a rudimentary plugin version display window in the IDE. How hard can that be for them?

  13. @Brendan Murphy
    I take exception to anyone assuming anything about our development environment. Over ten years with over two dozen commercial projects a year have said we’re doing *something* right in regards to plugin management.

    I’m looking at RBVersioner and asking what does it do for me? And I have to say nothing because I’m already managing my plugins and versions well now without any utility.

    So I have to ask is this a solution in search of a problem?

    Something *might* be better than what’s available now but how much time and effort do I devote to a problem that few seem to be suffering from? I just don’t see how I can justify the development costs for a new product that only a handful of RB developers would purchase. If I would use it for our projects I could justify the time and expense but, again, since I’m managing fine now…..

  14. if there was a good way to manage the plugins (which ones are loaded with a given source code – which version of the plugins too), that would be a big help to developers. not sure how easily this can be done due to the plugin architecture that Real uses.

  15. Jens Bendig :
    No, no and no. Since I think that every Plugin is a problem, the management of those would generate a super-problem.

    as a developer, I need the plugins to be managed. are they they true issue or not? dont know, and in the end I dont care. I care if they cause me problems. If there was a tool that mitigated the issue, then YEAH! we have a winner!’

Comments are closed.