I am new to rails and have a question regarding the plugins. It seems there are two approaches you can take when using a third party plugin in a ROR App:
1) install a gem using sudo gem install GEM, and then "require" it in your rails project
2) install the plugin using script/generate plugin install PLUGIN. The plugin in code appears in your vendor directory and then you are good to go (sometimes, i could not get Devise working via this method).
Since it appears both of these methods accomplish them same thing, why should I choose one method over the other.
Thanks,
Try to install the gem version of something when you can. There are a couple of benefits you get over plugins:
You can have them enabled or disabled for specific environments
You can update them via gem update. With plugins, you'd have to manually go out and update them yourself.
They are shared system wide, so if you create a new project, you can use them without having to reinstall them if you used them in a previous project. You'd have to copy/paste plugins.
Plugins are specific to rails, but gems are not. It's possible to use a gem outside of Rails.
You can still unpack gems to your vendor directory by running rake gems:unpack. This is useful to "lock in" gems to their current version, and also makes for quicker deployment since you don't have to fetch them from a 3rd party site (which is the case if you do rake gems:install).
Related
i want to know how to install a specific gem with a certain version in rails app vendor so as not to affect other gems installed in the whole system
as the server holds lots of rails project with different gems' specifications
The simplest answer is to just use Bundler to manage all your gems. That way, you're protected if the versions installed on the server change.
You can get more information here: http://gembundler.com/
Just install it as a plugin. So if it's hosted on github, for example:
rails plugin install "path_to_git"
or with Rails < 3
script/plugin install "path_to_git"
But Dan is right, a much better approach is to use rvm and bundler. If you have lots of rails projects as you say, this will save you a TON of version conflict headaches down the road.
On http://github.com/collectiveidea/delayed_job
it says:
To install as a gem, add the following to config/environment.rb:
config.gem 'delayed_job'
Run rake gems:install
versus
To install as a plugin:
script/plugin install git://github.com/collectiveidea/delayed_job.git
What is the difference between installing it as a gem or as a plugin?
Also, the first method just install gem 2.0.3 which might be the tobi's version? (rake gems:install installs the version by gem list -r delayed_job) Is it http://github.com/tobi/delayed_job ?
The "plugin" method specifically says it is the collectiveidea version? Doesn't it matter which one you install?
Both the Gem and the vendored plugin refers to the collectiveidea's fork. In fact, collectiveidea is the current maintainer for the delayed_job Gem on RubyGems.
That said, generally speaking installing a plugins as a Gem has many advantages.
You can install it once and use it in many different projects
You can take advantage of dependency resolution
You can upgrade just changing version number
You don't need to store the entire plugin code in your SCM
So, why you can install a plugin "as a plugin"?
There are many different answers.
At the very beginning, Rails plugins came as simple libraries. Time passes and developers started to notice the advantage of packaging plugins as Gem.
Also, before Rails 3, some plugin features were only reserved to plugins and not to Gems. For instance, before Rails 3, plugins could bundle rake tasks while there wasn't a way to inject new rake tasks or new routes into the main application.
In the last two years, the most part of Rails plugins offers the ability to be installed as a plugin or as a Gem. With Rails 3 and the arrival of Bundler, I'm sure plugins are going to be deprecated in favor of Gems.
That are 2 different repositorys,
maybe you shoult try
config.gem 'delayed_job', :source => http://github.com/collectiveidea/delayed_job.git
Look at: http://ryandaigle.com/articles/2008/4/1/what-s-new-in-edge-rails-gem-dependencies
Btw. maybe you want to look at a maybe better solution: resque - see http://ruby-toolbox.com/categories/queueing.html for a comparison of used queing gems
When you install a gem it will be available for all apps, in case you use a plugin - just for an app it's installed into.
The basic difference is a gem is something that gets installed on the system running your Rails application, whereas a plugin is installed along with your application, plugin does not get installed on the system level.
suppose you are using rvm and let us take this example.
we have two applications app1 and app2
both are running on a common rvm gemset named gemset1
when you add a gem in the gemfile of app1 and run bundle install and then being in the same rvm gemset which is gemset1, if you run the second app app2 the gem will be available in the second application as well
Whereas with the plugin it will not be the case because plugins get installed on application level and not at the system level
This may be a very lame question, but still I am confused when should I use a gem and when should I should use a plugin in my project.
What's the basic difference between them?
The basic difference is a gem is something that needs to be installed on the system running your Rails application, whereas a plugin is deployed along with your application. More specifically, plugins live in vendor/plugins whereas gems need to be install using rake gem install gem_name.
As for when to use each, gems tend to be easier to keep up to date, but more specifically, some gems use native C code and are compiled specifically for a given operating system (such as Nokogiri). These need to be installed as gems as they will not work when moved to another system. Whereas some things like acts_as_commentable use straight ruby code and can be moved from system to system.
From RailsGuides:
A Rails plugin is either an extension or a modification of the core framework.
From Rubygems.org:
A gem is a packaged Ruby application or library.
So, the biggest difference between the 2 is that Rails plugins are specifically made for use within Ruby on Rails applications, whereas gems aren't.
For example, let's look at Geokit.
The gem (geokit-gem) provides the fundamental location-based operations.
The Rails plugin (geokit-rails) mixes location finders into ActiveRecord.
Here you can see that the gem provides the core of Geokit. This gem can be used anywhere, not just a Rails app. The plugin provides additional features for those who are using geokit within a Rails app. In this case, using the plugin as well as the gem is optional.
When you install a plugin in a project it can be used only in the respective project. But if u install a gem, it can be used by every project. This is the main difference of Gem & Plugins.
Gems are distributed by rubygems, which is the official ruby library package manager. Plugins is a (probably hacky) way for rails plugins. I recommend you using gems whenever possible, due to dependency resolution. Rails3 ecurages that by packing with Bundler.
I use gems whenever a gem works as I wanted to and plugins when I want to do a custom change for a specific rails application and not affect all of my system.
I want to use the LinkedIn gem But not the one that I get when I type
sudo gem install linkedin
I want a specific one that somehow has done patches to. It is a fork of the original which is:
http://github.com/jbasdf/linkedin
I have downloaded sources from the above link, and use "rake" command to build a gem locally. So everything is working fine locally.
But now I have a question. How can I setup this folked gem on the server (engine yard)? I am not sure how to bild a gem on the server in this case.
Many thanks!
If the pre-built gem is available on a server(gem cutter) you should be able to use Trip's method.
If not two options spring to my mind:
1) Write a chef script that clones the source from github and builds it.
2) Use bundler with its built in support for building gems from a git url. EY fully supports bundler.
I think the latter would be a better choice, as it completely removes the need to use EY's UI for managing gems and is a step towards Rails 3 compatibility.
You can log into EY's cpanel. On your dashboard, Click "Application" in your instance, and then click on the Ruby Gem Icon. In this panel you can download gems to install on your server including what version you want them as well.
I am facing some problem with rails gem when deploying to a differet machine.It requires some extra work on installing gem.Which is most suitable for a rails project.Plugin or Gem.
For Some gems there is no corresponding plugins found.
I am searching for advantages of using plugin over gems and vice versa.
You can unpack gems to your Rails application, which will make sure that they are deployed together with your application:
rake gems:unpack:dependencies
Now you no longer have to install the gems on the server you deploy to. This already takes care of most of the deployment issues. Most others are solved by Bundler, which will be included with Rails 3.
If you can, use gems over plugins. Gems are generally easier to manage, because their versioning is superior to plugins. For public Rails extensions, I see no reason to use plugins instead of gems, but some authors only offer one of the two. In that case you have no choice.
I usually always use a plugin if it is available as it gets frozen into the project, meaning there are no issues when the project is deployed. You can freeze gems into a project but if they require a native build it causes more hassle than it's worth from my experience.
My understanding is gems are easier to upgrade than plugins.
You should also look into the rails 3 bundler which is used to handle these deployment issues.
For me, plugins are preferred. I've run into many a situation where I'll have an improperly configured environment.rb and gems won't have versions assigned to them. Then the server admin does a:
sudo gem update
And now my rspec tests won't run because the update installed test-unit 1.2.2 and my specific setup needs 1.0.1 (or something).