I've been wondering for awhile if the Plugin system is something worth taking out of Rails. It's not that I have anything against Rails plugins, but I cant find any way in which they are superior to RubyGems.
Two benefits I have heard are: The code can be packaged with the application and Rails auto-loads plugins. While I agree that these two things are important, it's possible to achieve the first by using gem unpack and it's also possible to auto-load unpacked gems.
Update: I hadn't even seen this post about Rails autoloading gems, by Chad, until today. It seems that more than a few people would like their gems to play nicely with Rails.
Another benefit I've heard is that plugins are easier to create. I've never created a plugin, but Dr Nic has made it quite easy to create gems using newgem.
While I cant find any features that plugins provide and gems do not, RubyGems do provide features that are not available in plugins such as versioning and dependencies.
So, a question and a request:
What benefits do plugins provide?
If there are no benefits to plugins, create gems for your reusable Ruby code instead of plugins.
Its not about what plugins over more then gems its about that plugins are a accepted way of extending rails.
ReplyDeleteAnd this acceptance can be found in the way plugins are installed (and automaticly integrated into rails by allowing things like install.rb). It maybe just as easy to use rails but its not the common accepted way as proposed by the rails core team....
If the core team would make something like script/install plugin gem_name (and allow the gem to be auto_loaded and allow it to have install.rb). It maybe become the new way of extending rails...
-- Abdul
I meant that it maybe just a easy to use gems (as plugins) but...
ReplyDeleteIt's true that plugins are common practice. But, the plugin code doesn't come for free. Code requires maintenence, which takes time from core developers.
ReplyDeleteThe plugin system can also be confusing for developers new to Ruby on Rails. It's not clear whether to use Gems or Plugins.
So, should we support a system with nothing on the pro list and a few things on the con list simply because it's the accepted way?
So, should we support a system with nothing on the pro list and a few things on the con list simply because it's the accepted way?
ReplyDeleteIsn't that's the very definition of "opinionated software?"
It's not a matter of objective criteria, but what *feels* right.
The distinction was always clear to me: gems are distinct general purpose ruby library packages and plugins are distinct general purpose Ruby on Rails plugins. Let us not forget that not all Ruby users are Rails users. Wouldn't a whole bunch of gems usable only in Rails pollute the gempool a bit?
ReplyDeleteIf you would like to make Ruby code reusable, than use gems. If you want to make reusable code for Rails, use either plugins or gems.
ReplyDeletePlugins are installed locally for a project, gems, well, could be installed the same way too, but they have more bureaucratic initialization, which doesn't make them feel like a native part of your application (I mean ability to 1. easily install 2. easily modify/fix/tune).
In my opinion, gems should be consistent libraries and should be installed globally for your applications. Plugins, in contrary, should be small, flexible chunks of functionality just for your app, which you may want to tune in the future.
Jay, we really wanted to reuse RubyGems but it wasn't designed for the task: plugins are like a gem repository for a single app. Gems give you a system-wide repository. Unpacking a gem gives you its guts in a directory - not so useful.
ReplyDeletePerhaps an enterprising hacker could refine RubyGems to accept a full GEM_PATH rather than a single GEM_HOME.
In the meantime, you can "install" plugin gems by creating a stub plugin whose init.rb requires 'whatever_plugin'. Why not just toss those requires in your config/env.rb, then?
@Robert: That is a fairly logical line in the sand. But, I don't agree that the plugins would polute the gem pool. Even if it were true, implementing a seperate code reuse system doesn't seem like the best answer.
ReplyDelete@Oleg: I've never had a problem doing a 'gem install [gem]', 'gem unpack [gem]' and then making local to the unpacked code. I've also never had a problem getting a project approved on rubyforge. And, frankly, many of the plugins I've used could really be much better if their maintainers cared to create a more mature project.
"In my opinion, gems should be consistent libraries and should be installed globally for your applications. ..."
Sorry, I couldn't agree with this less. I wouldn't want my application to depend on global libraries any more than I'd want it to depend on global variables. All my apps depend on code that they own.
Jeremy said: "Unpacking a gem gives you its guts in a directory - not so useful."
ReplyDeleteI'm not sure I understand this statement. How is unpacking a gem in vendor any different than doing a script install? Don't they both put all the code for the library in vendor?
Also, plugins follow a standard and that's the only reason they are auto-loaded. For gems we want Rails to auto-load we could follow the same standards. [Just to be clear, I'm talking about unpacking gems so the application contains the gem source] Am I missing something or is auto-loading basically a non-issue for whether we should use plugins or gems?
The rapt project is a fork of ./script/install with some enhancements. It wouldn't be hard to modify that so "rapt install some_library" also searches the gem repository on Rubyforge and unpacks it.
ReplyDeleteJay,
ReplyDeleteIts not about what plugins offer more, its what they don't offer. They are simple, just an init.rb file in a directory and you have a ruby on rails plugin (with handy things like rake tasks, install.rb, tests, enc). No packing, no putting it on rubyforge (to distribute it), enc...
I am even again's versioning of plugins, making plugins that depend on other plugins enc... all things that make plugins much more complex then they need to be....
Why not make a plugin (;)) that makes usage of gems as easy as usage of plugins. And why not make a couple of tutorials that show that gems are as easily created as plugins and then try to convince the core team : )
Rails plugins don't work anyway.
ReplyDeleteI find myself trying to install them and then re-writing the same damn functionality by hand because there are bugs or rails won't find the plugin or the dependencies won't load or the developer never tried it using windows or my computer is just being pissy or whatever...
It's extremely frustrating to be promised all this great functionality and have it without exceptions just plain not work.
- dantaeus at google's mail service..
I think Oleg Andreev put it best earlier. Gems are for Ruby. Plugins are for Rails, the framework. Gems are like PHP's Pear bits. I think what confuses many, is that many Rails Plugins are very 'low level' and many Gem's encapsulate high-level routines that are more 'Rails' framework-related than Ruby language. Gems probably shouldn't encapsulate high-level Rails behaviour, right? I'm guilty of breaking that myself.
ReplyDeleteWhy not make a plugin (;)) that makes usage of gems as easy as usage of plugins. And why not make a couple of tutorials that show that gems are as easily created as plugins and then try to convince the core team : )
ReplyDeletecheck out http://rubyforge.org/projects/plugems/
To Michael and Oleg: that's what dependencies are for. If a gem depends on one of the Rails gems (e.g. activerecord), then you know it's a Rails-oriented gem. Alternately, maybe you are using ActiveRecord in Camping and the functionality provided by a "Rails" gem (which depends on the activerecord gem) would be useful to you even though you aren't using Rails. There is no "pollution" of the gem pool as long as dependencies are explicitly called out.
ReplyDeleteThere is certainly room to argue that you should be able to tell which gems a gem depends on before actually attempting to install it. In fact, I'd very much like to see such functionality in RubyGems (and maybe I'll hack it in). But that has nothing to do with Rails.
Can we use the plugins in the making of gems???
ReplyDeleteif yes, how??
please can any one help me???