Allow disabling built-in plugins

[rbp]

Currently the plugins distributed with will are always active. There should be a way to enable the user to disable them (either because their functionality is undesirable, or because the user wants to customise their behaviour).

I can submit a pull request for this. The idea is to add a flag to WillBot.init, and pass it on run_will.

[skoczen]

This is something I've thought a lot about - and allowing the reverse of this as well. Is there a way we can allow PRs for useful plugins, and ship will with more batteries included, leaving the enabled ones completely up to the user?

Hubot has a pattern for this that works, but I'm still not crazy about, though I haven't thought of something better. Err has a big pattern of doing it all in the bot, from a big source repo on the fly, but that felt way too complex to me.

In the hope of an easier solve and more information, which built-in plugin(s) are giving you trouble?

Thanks!
-Steven

[rbp]

Yes, that'd be interesting. Perhaps have a specific Github repository, like a poor man's "package repository", to which people can create PRs and which Will uses by default to find plugins. A user could, via config, add other repos (which allow for private plugins, for instance) and remove the default one. Then in config the user could specify which plugins (or plugin directories) would be active, or all, or none.

Coupled with that, will could come with a small set of special plugins, enabled by default, for admin tasks. Including, specifically for this case, enabling, disabling and listing plugins.

How does that sound?

(In my specific situation, it's not that a plugin is giving me trouble, but I'm setting the "character" for my bot as that of Wodehouse's Jeeves, and I don't want it saying, for instance, "I LOVE cookies", which would be out of character :))

[skoczen]

Ooh, that's a really lovely idea - I'm gonna mull it some more, but I don't think I've encountered anything that elegant. Could just be a single setting, too: WILL_PLUGIN_REPOS. Man, that really could be nice.

The on-the-fly enable/disable I'm not crazy about though. A few other bots do that, and it just feels too clever to me, and too tough to reset/debug/change. I think this is heading down the right path though.

Specific situation: darn. I was hoping it wasn't the cookies. I really like the cookies. Gonna give this some thought and figure a good solve!

[rbp]

The on-the-fly (dis/en)abling is very handy when 1) you want to reload a module - though reloading could be a specific options, instead of *abling, 2) when you install a new plugin and so don't have to stop and start the bot, 3) when a plugin goes crazy (i.e., flooding a channel), 4) when you realise someone is abusing a plugin etc.

1 and 2 are highest in my priorities, I'd say.

As for the cookies: don't worry about it :) for now I'm using my own fork anyway (I've added things like plugin methods that only answer to admins etc), and WILL_PLUGIN_REPOS plus, say, WILL_ENABLED_PLUGINS solves it.

[skoczen]

Out of curiosity, how are you deploying your will? We have ours on CD here, with a "test" channel set up that all our dev setups connect to by default for debugging. The test channel handles most of our 1 and 3 cases, and 2 and 4 we handle by pushing new code to github (since it goes live <2m after push.)

Curious to hear your setup, and see if there's a good solve for those issues in a general way. Have some time this week, and hoping to get the plugin enable/disable/easy-to-share problem solved. All thoughts welcome.

[rbp]

Haha rather poorly ;)

As we were playing around with a few solutions, I still have it running on my notebook :) I have a local git repo for plugins and local changes I make on Will, for experimenting.

But we've all come to rely on it, so this week I'll deploy it on heroku and make it a "proper" deployment.

In any event, this "setup" is why I want to be able to disable specific plugins (or repos), and even do it while will is running. It makes for a very quick cycle of have-a-need/test/deploy, or find-a-bug/fix/deploy, without having will log in and out of the chat all the time.

Anyway, Will (as I said, called "Jeeves") sits on our development channel. Now that it's more stable and we're getting to use it, it will probably be used on other channels as well (for mobile developers, and possibly the one for the product people).

(Sorry I didn't answer earlier, I was away on a long holiday)

[skoczen]

Thanks for the reply, and the good info - this and the somewhat related concerns that came up in #36 make me realize several things:

1. We need much better docs on how to set up will in a dev environment, for easy debugging. When we're hacking on will here, we have special test channels that we connect to only, and then the cycle for bugfixes/testing is really rapid. Our current setup does involve restarts, but in practice, what's been more annoying to me in developing is re-typing the test commands. Having to type "reload" would be double-pain, at least to me. However, to fix that pain point, even more than a @will restart plugin x, I'd love to have a --dev flag that auto-watched and live-reloaded plugins on save. Thoughts?

2. We need proper config. I put a draft config in the other issue, but moving forward, I'm looking at a setup that allows you granular control of which plugins are loaded, with includes, excludes, and sane defaults. It'll also allow us to bundle in a bunch more functionality with will.

To that end, I'm starting #37, which will pull together all these threads into a cohesive release. Thanks much for pushing on these issues, and helping shape a better, easier to use will!

[rbp]

Cool, #37 looks great :)

Regarding auto-(re)load, I think it's an excellent idea, and it can be useful even outside a dev scenario. So that could be simply a configuration options. That's not to say that a --dev flag wouldn't also be handy (and it could, for instance, auto-set the auto-reload options to True).

[skoczen]

Since the convo and implementation for this is happening at #31, closing this issue!