Show HN: my weekend project, a "framework" for IRC apps/bots

24 points by llambda ↗ HN
This is a little project I've been working on for a while in order to better learn Python. Although IRC may not exactly be the most exciting medium, I still find it to be fun and useful, this interest lead me to writing a bot. In doing this I realized that what would actually be more interesting would be if I had a framework. There may already be such a thing, certainly there are IRC libraries, but I don't know if they're well-suited to deploying bots. At any rate if for no other reason than the fact that I am relatively new to programming and eager to learn I decided to build a framework. The API is heavily influenced by Flask and other similar frameworks. It's fairly easy to write a simple bot and the framework will do things like reload the bot source on the fly as changes are made, attempt to reconnect when the connection is lost, and dispatch plugins in a threaded manner. I'd love to read any feedback! :) Here's the project on GitHub --> https://github.com/maxcountryman/irctk

11 comments

[ 3.0 ms ] story [ 42.0 ms ] thread
Clickable: https://github.com/maxcountryman/irctk

Just a clarification, IrcTK is not itself a bot, it's a framework for writing IRC applications or bots. So this is different from say Supybot or some other bot that was written as a self-contained application in that instead of writing plugins for those bots with IrcTK you import the framework and write your own bot (essentially a set of plugins as either commands or events).

Looks cool, I tried my hand at this not too long ago if you're interedted in comparing notes: https://github.com/coleifer/irc/
Oh interesting. I'm looking at it now. How are you handling plugin dispatching? Are the plugins threaded?
(comment deleted)
Why is it called irctk if it doesn't use Tk??

I recommend you hot-reload code. My IRC bot is a humble 150LOC split over two files. The basic bot logic to connect to a network lives in the script I run. That bot object sets its handler to an object imported from the second script, checking that second script's mtime regularly and if changed, reloads that module and re-sets the handler object.

It lets me change bot behavior on the fly without disconnecting, which is a pretty important thing to do if you don't want to be guilty of JOIN/PART spam.

  def set_handler(self, reloaded=False):
      self.handler = pigbot_handler.PigBotHandler(self, reloaded)
      self.handler_mtime = os.stat(self.handler_file).st_mtime
  
  def start_timer(self):
      self.timer = threading.Timer(1, self.check_handler_file)
      self.timer.start()
  
  def check_handler_file(self): 
      if (os.path.exists(self.handler_file)):
          mtime = os.stat(self.handler_file).st_mtime
          if mtime > self.handler_mtime:
              self.log('pigbot_handler changed, reloading ...')
              reload(pigbot_handler)
              self.handler_mtime = mtime
              self.set_handler(reloaded=True)
      self.start_timer()
1. TK == ToolKit a la libraries such as Werkzeug (toolbox)

2. It already does this. See the description. :)

I was looking at the example code, where bot logic and the run() was defined in the same module. That can't be reloaded.

The reloader looks like it works for "plugins." It all seems unnecessarily complex to me.

Also, your handlers should be provided with the channel in which the command was triggered. That doesn't seem to be set in the context dict that is passed to commands.

Another thing is that the bot model is very restrictive, as I've often seen with this sort of tool: You have events and commands, and that's it. It looks like the case of "try and match this regex, and do something with the result" would be possible, but made overly complex.

I'm not sure what you mean when you say it can't be reloaded. In fact the only part of the code that cannot be hot-loaded is the socket connection (although this can be achieved if done properly) but because everything is decoupled, it's simple to reload even the framework itself, on the fly. And of course, the application written with the framework is wholly reloadable. This works just as Flask does and is in fact modeled after it.

Edit: I'm not sure why you think it would be restrictive, the entire line is available, it's conveniently parsed, and you're free to attach plugins to commands and hooks (what else do you want to attach them to, that's pretty much the extent of what happens with IRC). Regex? No problem: attach a function to an IRC command (this is the event decorator) and check the line for your patterns (context.line). If it seems too complicated to you or for your application, that's fine, as I said, this was a project I did for my own edification.