# Plugin generator gems **URL:** \ **Category:** Rails\ **Created:** [November 12, 2006, 5:59am UTC](https://www.ruby-forum.com/t/plugin-generator-gems/75671 "2006-11-12T05:59:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![urbanus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/90ced4/32.png) [@urbanus](https://www.ruby-forum.com/u/urbanus)\ **Post date:** [November 12, 2006, 5:59am UTC](https://www.ruby-forum.com/t/plugin-generator-gems/75671/1 "2006-11-12T05:59:18Z")
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](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 “\: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](http://goldberg.240gl.org) ---
**Author:** ![urbanus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/90ced4/32.png) [@urbanus](https://www.ruby-forum.com/u/urbanus)\ **Post date:** [November 12, 2006, 11:55am UTC](https://www.ruby-forum.com/t/plugin-generator-gems/75671/2 "2006-11-12T11:55:35Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![urbanus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/90ced4/32.png) [@urbanus](https://www.ruby-forum.com/u/urbanus)\ **Post date:** [November 12, 2006, 12:55pm UTC](https://www.ruby-forum.com/t/plugin-generator-gems/75671/3 "2006-11-12T12:55:39Z")
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](http://rubygems.org/read/chapter/3) Thanks for your comments Larry. Regards, Dave ---
**Author:** ![urbanus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/90ced4/32.png) [@urbanus](https://www.ruby-forum.com/u/urbanus)\ **Post date:** [November 15, 2006, 8:57pm UTC](https://www.ruby-forum.com/t/plugin-generator-gems/75671/4 "2006-11-15T20:57:32Z")
On 11/11/06, urbanus [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://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