So I take it that there isn’t a document/article that
when to use/not to use ?
rationale of using one over the other?
Presumably you’re talking about when to write one type of reusable
library as opposed to another? There are no clear-cut “pros/cons” to
either since their appropriateness depends on what exactly you’re
trying to share. However:
If you’re writing a Ruby library that could be used for projects beyond
Rails, make a Gem; it’s the de-facto standard for distributing Ruby
libs. Gems have nice features like being able to load a specific
version, and automatically installing dependencies, but are most
typically installed as part a system’s global Ruby library set, rather
than being associated with a particular application. If you go this
route when writing enhancements for Rails apps, it can add another
hop-skip-step to your deployment (i.e. ensuring that all the
appropriate gems are either installed or unpacked into your app for
each target machine).
If you code only makes sense in terms of a Rails application, or
overrides/enhances some features of Rails, you’re probably better
creating a plugin (or a plugin ‘stub’ that loads a gem, if you’re
feeling fancy). Because plugins are ‘simpler’ than Gems, they can be
included into an app easily (svn externals are particularly useful) and
so there’s a little bit less to worry about with deployment.
If you want to share Rails-specific things like controllers, routes,
migrations and such, write a plugin and request that users install the
engines plugin along side it, since it makes sharing such things quite
easy when appropriate.