Depending on your vendor directory

RubyGems are great for local development, making it easy to stay on top of things, such as when your favorite libraries are updated.

But when you’re getting ready to deploy your application, you want to keep everything in sync. Chances are that we may not have installed the BizarroGem on the TextDrive Shared servers, or if we have, there’s no guarantees that we’re using the same version as you are, since we don’t run gem update every day.

But there’s a simple solution; the almighty vendor/ dir in your rails application root. It’s added to the $LOAD_PATH (where ruby looks for files to require) when Rails is loaded.

We like to recommend sticking your external dependencies in there, for the BizarroGem we could put it in vendor/bizarro_gem and load it from the environment, or some other suitable place, with a simple
require 'bizarrogem/bizarro_gem'

Not only are you keeping your dependencies easily in sync between your production and development server, you’re also sure that everyone else working with you are using the same version of everything when it comes to external libs. And you can easily keep everything in Subversion to track changes, making the deployment a breeze.

If you don’t want to dig up the gem source directory on your system (usually in /usr/local/lib/ruby/gems/1.8/gems/) you can use the unpack feature of Rubygems, just type:
$ gem unpack BizarroGem
and it’ll “unpack” the installed gem into the current directory.

This is the approach we took when building Strongspace. For instance, we were using Lucas’ credit card validation gem at first.
But it had some namespace clashes with some of our code, so we copied it into our vendor/ dir, renamed the clashing class (we could also have put it in it’s own module, but a simple rename was easier). A svn up later and everyone on the development team was validating creditcards like there was no tomorrow.

RubyGems is a sweet system for packaging, but for deployment, local dependency installs run anywhere irrespective of whether or not the gem is installed.

·:· Posted 4 November 2005, 08:40 by Johan Sørensen to Rails  |  

  1. That’s a good tip. I rememeber trying this before but somehow it seemed not to work if a newer version of a certain gem was installed on the server.

    I must have done something wrong before because after:
    running gem unpack RedCloth -v '3.0.3' in the vendor dir
    adding require 'RedCloth-3.0.3/lib/redcloth' to environment.rb
    svn add, commit and update everything works like a charm.

    Thanks!

    — Thomas Maas    4 November 2005, 12:22    #
  2. What about code that is not packaged in a gem form, and that requires some native compilation? Does this need to go trhough a support ticket? (I am thinking Ruby::Imlib2 here)

    — victor    4 November 2005, 12:29    #
  3. update: well the above gives a whole list of already initialized constants. Somehow the gem is activated before the vendor dir is being required?

    — Thomas Maas    4 November 2005, 12:31    #
  4. Thomas, RedCloth and BlueCloth are a little special since the ActionView helpers loads them (for the textilize/markdown methods).
    So you’ll have to stick the redcloth.rb directly in vendor/ (and not in a subdir) so that Rails loads that one over the gem..

    Redcloth has a VERSION constant you can look at to see what version is loaded (launch the ./script/console and type RedCloth::VERSION)

    — johan    4 November 2005, 18:51    #
  5. Victor,

    Sure thing, if you can’ install it locally, put in a support ticket and we’ll probably install it.

    — Michael Koziarski    4 November 2005, 19:48    #
  6. As rails is a gem, is it possible to copy rails to the vendor/ directory so that one has not to install rails on the production machine? Would this be a possibility to deploy rails apps on webspace which just offer plain ruby 1.8?

    — Markus    8 November 2005, 16:50    #
  7. Markus:

    Yes you can install rails into the vendor directory, this is described under ‘EdgeRails’: http://wiki.rubyonrails.com/rails/pages/EdgeRails

    They are referring to running rails from the SVN trunk, but you could put any version you want…

    — Patrick Ritchie    8 November 2005, 21:49    #
  8. Markus, sure, that’s how you run edge rails (off the svn trunk).

    vendor/rails/actionmailer
    vendor/rails/actionpack
    vendor/rails/actionwebservice
    vendor/rails/activerecord
    vendor/rails/activesupport
    vendor/rails/railties

    — johan    8 November 2005, 21:51    #
  9. Thanks, Patrick and johan.
    Reading http://wiki.rubyonrails.com/rails/pages/UnderstandingHowRequestsAreRouted also helped me to understand why this approach can work.

    — Markus    9 November 2005, 16:37    #