[Nitro] ratchets, parts and plugins

transfire at gmail.com transfire at gmail.com
Mon Nov 20 10:04:07 EST 2006

transfire at gmail.com wrote:
> hi--
> was looking at rails plugin script this evening and thinking about what
> they are doing. my understanding is this: each rails app has a
> vendor/plugins directory, where plugins are installed via the plugin
> script or the rapt utility. (assuming i got this right) while i see the
> point considering the deployment limitations of web apps, doesn't it
> seem rather amazing that essentially copy-and-paste reusability is
> getting so much play?
> i developed my own "plugin" system (before i knew how rails' worked)
> and it functions as an indirect require. so you do:
>   require_plugin 'someapp/pluginname'
> and this refernce file is read from a shared store which simply
> contains a list of lib files to actually require. the system is
> extremely simple, effective, versitle and reusable, and w/o
> copy-and-paste --plugins are just installed like any other app.
> of course I understand that there is a need for reusable copied parts
> and ratchets has a feature for that, which naturally fell out of reap's
> seed tool, eg. scaffolding a project. if you think about it,
> scaffolding a project is essentially copy-and-paste reusability. so i
> was able to integrate the two concepts. one can do:
>   project scaffold --part part_name_or_url
> to add a pre-packaged part to a project. for a completely new project
> it's
>   project scaffold --part new
> though one can just use 'project scaffold' b/c new is the default part
> in none is given.
> but now that i look at what rails is doing it appears i perhaps
> reversed the concepts. is a plugina part and a part a plugin ... had
> you all been talking about parts as analogous to rails' plugins, or
> different in regards to their reuse? myself, i sort of prefer the term
> 'scaffolding parts' (or just 'parts') for copy-and-paste reusability,
> and plugins for the other.
> one thing i did learn from rails plugin system is i need a way to
> unistall parts too. since ratchets is more flexible, in that in can
> install files anywhere within a project layout, its not as simple as
> removing a plugin folder, so i'll have work that out via some for of
> manifest --and it may have to wait for a later release.
> any thoughts on all this?

Due to the mailing list issues I imagine few if any of you have had a
chance to read this yet. Well, maybe that's a good thing. I've been
thinking about it some more and have concluded that it is a mistake to
further promote copy-and-paste reusability. Not only does it lead to a
great deal of wasted memory/storage space, it encourages bad
non-reuable design, which further exaserbates the problem.

The upshot is that I removed the parts scaffolding I mentioned before
from ratchets. (There's still the ability to create new project
scaffolding of course.)

If you want to make a nitro plugin, this is how it can work: just
create a normal project, then add to the project:


Where 'myplugin' is simply a text file with a list of files to require
from the myplugin project. Eg.


Then in a nitro app you can simply use:

  require_plugin 'nitro/myplugin'

This doesn't handle plugin versioning at this point but that can be
integrated in the future. One of the nice things about this too is that
it works just as well with or without RubyGems .

Are there any conditions in which this would not be enough to handle
plugins for nitro? If so, it should be easy enough to build a wrapper
around this basic functionality. But I would like to know what they
would be, b/c maybe there are some general improvements that can be to
this plugin system.


More information about the Nitro-general mailing list