Writing Plugins | 83Plugins and other vendor code can be managed very well with a decentralized ver-
sion control system. These systems afford much more flexibility, especially in com-
plicated situations with multiple developers and vendors.
A tool is available,hgsvn,*which will migrate changes from a SVN repository to a
Mercurial repository. This can be used to set up a system similar to Piston, but with
much more flexibility. One repository (the “upstream” or “incoming”) can mirror
the remote repository, and other projects can cherry-pick desired patches from the
upstream and ignore undesired ones. Local modifications suitable for the upstream
can be exported to patches and sent to the project maintainer.
Writing Plugins
Once you know how to extend Rails by opening classes, it is easy to write a plugin.
First, let’s look at the directory structure of a typical plugin (see Figure 3-1).
There are several files and directories involved in a Rails plugin:
about.yml (not shown)
This is the newest feature of Rails plugins—embedded metadata. Right now, this
feature works only with RaPT. The commandrapt aboutplugin_namewill give a
summary of the plugin’s information. In the future, more features are expected;
right now, it exists for informational purposes. Metadata is stored in theabout.yml
file; here is an example fromacts_as_attachment:
author: technoweenie
summary: File upload handling plugin.
homepage: http://technoweenie.stikipad.com
plugin: http://svn.techno-weenie.net/projects/plugins/acts_as_attachment
license: MIT
version: 0.3a
rails_version: 1.1.2+
*http://cheeseshop.python.org/pypi/hgsvn
Figure 3-1. Directory structure of a typical plugin