On Sat, Sep 16, 2006 at 06:15:44PM +1000, Greg H. wrote:
} Hi all,
}
} I’ve been finding that I tend to want to “tweak” many of the plugins
that I
} download. I’m wondering whether:
}
} a) this is reasonable & I should maintain my own local plugins as such
for
} just my projects (I assume I could just change the plugin directory
name a
} bit) or
This is reasonable. Assuming license compatibility, once you include it
into your project it is yours to do with as you will.
} b) I should be trying to somehow override the plugin (see question
below)
} instead
Kind of ugly, but possible. You’d have to do it in the plugin’s init.rb,
though, so it probably isn’t worth it.
} Also some general questions in this area:
}
} c) With plugins can one override a particular method from the plugin
by
} dropping a similar file/module/class in the app area with just that
method?
No. Class/module autoloading happens based on the class/module not being
defined yet. Once it’s defined, whether because the appropriate file was
found in and loaded from the plugin or in lib, no other file will be
automatically loaded to satisfy the need for the given class/module.
} d) Is there a “update plugins” type command? i.e. does one need to be
} careful if you make changes in the plugin directory that they might
not be
} “blown away” via an update command?
The right way to handle this is with subversion and svnmerge. This
assumes
that you are using subversion for your project, of course. Instead of
using
script/plugin to get the plugin, you svn copy the plugin into place in
your
project and commit. You then svnmerge init (svnmerge is actually a
Python
script, and it makes merging much easier) and commit. Now whenever you
want
to update the plugin you can svnmerge merge, make sure you like all the
changes, and commit.
Google for svnmerge to understand the details of the process. I have
recently started using it and I am delighted with its functionality, if
not
its documentation.
} Tks
–Greg