Dynamic "plugin" discovery

[docwhat]

I haven't fully thought this out, but it'd be nice if you could point your ruby code at a directory full of .rb files, and they would:

• Magically be required
• The classes, that include Cinch::Plugins, would be added to the plugins list.
• !help would show all commands listed, or at least all plugins.
• !help would be routed to the right plugin for more information.

Ciao!

[dominikh]

We're unlikely to implement point 1 and 2 directly in Cinch, for various reasons: 1) It is too specialised to be considered part of the Core 2) It rather falls into the subject of wrappers like cinchize (which is maintained by @netfeed) 3) It can easily be added by yourself with a couple of lines

Regarding your points 3 and 4: 1) Cinch already has a built-in "help " command, which displays the help which is associated with a plugin 2) A total overview of all plugins/helps is not yet possible (but planned)

I am, however, considering removing the whole !help facility from the Cinch core to move it to an extension instead.

[netfeed]

Yeah, cinchize takes more or less care of the first points, but it's not really that much magic in it as it works more or less on config-files.

I guess i could add some sort of control mechanism that checks the dir your standing in when you start the bot if there's and plugins close by and then load them, but that would then require that there's no config options for the bot plugin

[cadwallion]

@netfeed I implemented something like that with my bot on top of Cinch that also allows me to reload plugins from scratch. https://github.com/cadwallion/cadbot_cinch/blob/tests/lib/cad_bot.rb#L67 I've thought about extracting that particular component out to a drop-in extension for Cinch but haven't moved on it yet. I'm also interested in fleshing out the help capabilities (especially when I have several commands with their own help messages within one plugin).

[dominikh]

that also allows me to reload plugins from scratch

I am curious as to how that'd work. As far as I remember, the current Cinch release does not offer any functionality for unloading handlers (even though that is in the works and in the develop branch, to a limited degree).

I couldn't find anything for reloading in the file you linked to, either.

Please enlighten me :)

[cadwallion]

I haven't pushed the reloading portion for Cinch outside my local repo because it's not fully cleaned, just the CadBot layer on top that removes the class constants and reloads the source for the plugins.

The code I have so far locally iterates across my CadBot#plugins array and pulls the element from Cinch#events that matches the Plugin class block. Once I've pulled the handlers the Threads are still going which is the current problem to tackle. Then I run CadBot#load_plugins again followed by Cinch::Bot#register_plugins.

My hope was to clean it up a bit this week after I finish getting test coverage up on CadBot.

Thoughts?

[netfeed]

Ah, but the problem isn't really how to set the options. It's more where options for the dynamically loaded plugins would live.

I doubt that there's actually a need for setting options for stuff you build yourself locally, but if you have a gem that's dropped in and you'd like to set options for it... Each network has is configed up in a config file right now for cinchize and you can set options for plugins there, but that kinda blows the point with having it loading dynamically as it still needs to be configed in the file...

But if we should move away from problems, then I guess an option for adding plugin dirs like this:

plugin_dir => "path/to/dir"

Options could be sent to the plugin if there's say a plugin.rb with a corresponding plugin.yml with the options in it.

Ah well, needs some more thought.

[dominikh]

@cadwallion Well then I'd ask you to not waste your time with implementing that unregistering thing, because I am already working on that, see e.g. https://github.com/cinchrb/cinch/blob/develop/lib/cinch/bot.rb#L327 -- even though that indeed doesn't yet get rid of the running threads.

[cadwallion]

@netfeed Right, what CadBot does is looks if there's a specified dir for plugins in the configs, and if not it loads from the plugins dir for all files that has Cinch::Plugin included. You CAN specify in the config or as part of the CadBot.new, but it will just magically work otherwise. A solution for something like that is possible today if we take the reloading off the table until unregister_handler is done.

@dominikh Alright, I will hold off on working on an unregister_handler and will tie my reload plugin for CadBot into your implementation when it's rolled out. Thanks for the heads-up.

[dominikh]

Closing this since the main idea, "dynamic plugin discovery" is the responsibility of tools, not Cinch itself.