Plugin generator gems

Rails
1

Plugins seem to be the way that a lot of the interesting work in Rails
is being done at the moment. Plugins are certainly very powerful, but
the way they’re installed could use some improvement. You can use
“script/plugin”, which does a screen-scrape of
http://wiki.rubyonrails.org/rails/pages/Plugins then uses Subversion to
install the plugin. But increasingly plugins are being written that
depend on other plugins, which in turn depend on others etc., and this
installation method doesn’t scale up very well at all.

Compare with package installation in systems such as Debian Linux,
where you just specify the package you want then dpkg handles the
details of downloading and installing the package and all its
dependencies, including updates where required. Wouldn’t it be nice if
installing plugins in Rails were like this?

I think this is achievable, using a combination of generators and gems.
The system could be arranged as follows:

  • The plugins are arranged as generators, with manifests and template
    directories.

  • These generators are packaged and distributed as gems.

They still get used as plugins in a developer’s Rails project. The
difference is that the
gems take care of the installation (NOT the runtime) dependencies, and
the
generators put the files into vendor/plugins/ in the developer’s
project.

After running the generator to put the plugin into a Rails project, the
developer could then run a Rake task to complete the installation. The
name of the task could be “<plugin_name>:install”. This would execute
the plugin’s “install.rb” file, generate any dependant plugins and
recursively run their :install tasks to get them set up too.

In summary the whole process might look something like this:

gem install someplugin_generator
cd myproject
script/generate someplugin
rake someplugin:install

This would install the “someplugin” plugin – along with any number of
dependencies – setting them all up in “myproject”.

My idea would be to start a project that provides generator gems for
lots of useful and popular plugins that are already around at the
moment. It would involve taking the authors’ original code,
re-arranging the files a bit for installation as generators, writing
the generator manifest and the gem specification files for each,
gemming them up, and releasing them as gems on RubyForge with credits
and copyright remaining with the original author.

Does this project interest anyone? Anyone got any better ideas? Want
to help?

Regards,
Dave Nelson
goldberg.240gl.org

2

You’ve given this some thought. It would be convenient for a plugin
to check and install missing dependencies. I wonder how often that
method would break because a dependent repository was relocated?

It also sounds like, your system would force all plugins to be
installed as gems, which require root access. This means that I
wouldn’t be able to add a plugin to a hosted application without the
help/approval of my hosting service. It’s not a problem when
developing on a box I control. And, if I use svn and deploy to the
hosted server only from my svn repository, it should get around that
issue. But, I thought I’d mention it, anyway.
-Larry

On 11/11/06, urbanus [email protected] wrote:

Compare with package installation in systems such as Debian Linux,

After running the generator to put the plugin into a Rails project, the
rake someplugin:install
and copyright remaining with the original author.

–
Best Regards,
-Larry
“Work, work, work…there is no satisfactory alternative.”
— E.Taft Benson

3

Hi Larry,

You’ve given this some thought. It would be convenient for a plugin
to check and install missing dependencies. I wonder how often that
method would break because a dependent repository was relocated?

Actually that’s one of the problems this proposed system would solve.
The gems would all be on RubyForge: the default gem source. Plugins,
on the other hand, are scattered all over the 'Net.

And with gems – unlike SVN repositories – you only have to specify
the gem name, not the path to the repository.

It also sounds like, your system would force all plugins to be
installed as gems, which require root access. This means that I

Acutally, no on both counts:

  • You could keep using whatever non-gem plugins you wanted. This is
    not a mutually exclusive system.

  • Section 3.2 of the Gem manual details how users without root access
    can install gems:

http://rubygems.org/read/chapter/3

Thanks for your comments Larry.

Regards,
Dave

4

On 11/11/06, urbanus [email protected] wrote:

directories.

script/generate someplugin

gemming them up, and releasing them as gems on RubyForge with credits
and copyright remaining with the original author.

Does this project interest anyone? Anyone got any better ideas? Want
to help?

Regards,
Dave Nelson
goldberg.240gl.org

I agree Dave, I think that we should be doing plugin distribution with
gems
ultimately. And if there are shortcomings with gems (like needing a way
to
do non-root installations) then we need to address that shortcoming in
gems.

Then as you say, we can easily gem install gem and then script/generate
the
plugin stub which defers most of its work to the gem.

This is exactly what we do with the MasterView project. We allow one to
install as a plugin or using gems and then generate the plugin stub
(which
defers most of its work to the installed gem).

Using gems is nice because you can easily require dependencies, etc.
Plus it
is the standard way to do ruby installs. So if anything is lacking we
should
be building it into that and have plugins leverage gems.

So we got this all working, but it was a bit of a pain to get it all
setup
properly to start with. Things could be much easier. If there was an
easier
standardized way to accomplish this then we’d certainly support it.

Jeff