Earlier today I came across a very cute picture of a bunny in Alexander Artemenko's blog post about Cony.
Cony is a Python web server using the bottle micro-framework that I've been loving so much lately. It's goal is to make it so you can easily write “bookmarks” or “commands” that you can access through the URL bar in your browser. You configure your browser to send keyword requests to the Cony server, and Cony parses it and runs your own custom Python code based on that. It includes commands for “g
Continue reading for more details of Cony and my hacking on it.
My hacking started with a simple wording change in the README, but quickly grew into code changes. My fork with these changes is up on GitHub, though I've submitted all my patches to Alexander as well.
The first command I wrote? It's a “nagios” command that will take the name of various clients who have nagios servers, and go to the URLs for their servers. I've been using multiple browsers on multiple machines lately, and have been having problems finding the Nagios URLs when I need them. I was going to just put up a simple page on one of our web servers that had links, but this sounds much more fun. So I'm trying that.
I added configuration options for changing the port and host that the standalone Cony server uses. I also added configuration options to run as either WSGI or CGI mode to integrate into an existing Apache server and not require running as a stand-alone daemon. I also made it so that these settings can be stored in a “conyconfig” Python module, so that you can have a local configuration without having to merge changes into upstream changes to “cony.py”…
The next thing I was going to do was make it so you could have your own commands module which Cony would pull from, similarly to the config changes, so that you could have local commands without having to patch them into upstream Cony changes as I had done with my initial command. However, I found that this functionality was already there.
I made some small enhancements to this “local_commands” module handling, and have switched my test Cony server over to using this version that I forked.
I also enhanced documentation, including documenting all of the above. The big, backwards-incompatible change is that now if you specify your own “local_commands” module, you aren't required to continue to use the default “help”, “g”, “p”, or “pypi” commands. If you want them, you can import them from “cony”, see the example in the documentation.
So, give Cony a try. It's good stuff! My fork, currently, has much improved documentation. So you may want to try the documentation in mine first, though all of the “configuration” stuff is different, and the “local_commands” are slightly different in the upstream Cony. I don't anticipate problems with getting it pulled upstream though…comments powered by Disqus