Monday, October 02, 2006

RubyGems: shared Ruby code

From the RubyGems website:
RubyGems is the premier ruby packaging system. It provides:
  • A standard format for distributing Ruby programs and libraries.
  • An easy to use tool for managing the installation of gem packages.
  • A gem server utility for serving gems from any machine where RubyGems is installed.
RubyGems is currently the mostly widely accepted way of distributing Ruby code. However, there are at least two other options for sharing code: svn:externals, rails plugins

Subversion Externals can be used to share code between multiple projects. Subversion Externals allow common code to be housed in a single repository. Any repositories that wish to share the code may simply create an external definition and link to the source. After a change is committed to the source repository, each check out that has the source repository as an external will receive the change when an svn update is issued. This provides consumers the ability to receive changes in real time. A notable consequence of this option is the risk of unexpected breakages when the external code changes. This can generally be mitigated by specifying a revision; however, this removes the ability to receive any future changes.

Rails Plugins are an additional way to distribute code that is useful for Rails. Rails Plugins are generally designed for shared code that is specific to Ruby on Rails backed applications. The most common complaint I hear is that versioning plugins can be problematic.

In fact, versioning seems to be a common problem with Ruby code distribution.

I'm not sure why RubyGems isn't more widely adopted as a distribution solution. Rake gives you a task to easily create RubyGems. RubyGems comes with a Gem Server that can be used to host gems internally. RubyGems also allows consumers to install gems and optionally specify a version.

Currently, RubyGems works well with Rails applications. To ensure that your application runs against expected code it is recommended that you unpack your gems in the vendor directory of rails.
focus:~ jay$ gem unpack sqldsl
The above code will create a sqldsl-1.0.0 directory in the directory in which the command is executed. After unpacking a gem you will need to add a line in environment.rb that requires the main file of the library. For example, to add the SQL DSL library to my Rails application I would add the following line to my environment.rb.
require "#{File.expand_path(RAILS_ROOT)}/vendor/sqldsl-1.0.0/lib/sqldsl.rb"
After adding the above line of code, the SQL DSL library is available anywhere in my Rails application.

Unpacking Gems in my vendor directory also ensures that my application only runs against code that I control and deploy. This mitigates the risk of my application breaking when gems are updated on my production box.

Give RubyGems a try.


  1. Anonymous10:43 PM

    Thanks for this helpful article. I am afraid is down right now though unfortunately. -Rudi

  2. Anonymous3:25 AM

    Hi Jay

    you may want to have a look at Piston (


  3. So, what's the difference between unpacking and freezing? Does unpacking work with gems and plug-ins or just gems?


  4. Anonymous10:58 AM

    Unpacking is when you:

    > gem unpack [gem name]

    Then a local copy of the gems source is put in the directory where you unpacked.

    I believe the Rails freeze task does the same thing.

    Cheers, Jay

  5. Anonymous9:35 AM

    Using svn externals can be dangerous if they point to a repository you don't control. In essence, you are depending on code you don't control. If the 3rd party decides to take their server down, you're SOL.

    Go with Piston, as suggested by thibaut. It's great!


Note: Only a member of this blog may post a comment.