Rails scraps
Posted by Daniel Wed, 16 May 2007 22:14:00 GMT
There’s some Rails things that I can’t seem to remember… because I often don’t think about them until first deployment. Here’s a few.
rake rails:freeze:gems (moves and unpacks Rails and it's gems into vendor) rake rails:unfreeze (reverses the above) rake rails:freeze:edge TAG=rel_1-0-0 (freezes to a specific version, modify the tag to suit) rake rails:freeze:edge(freezes you to the latest version in the repository (usually unreleased))
Next we have the same routine for any other Gems you might need:
'gem unpack ???????' while in your vendor folder.
Replace the ? with the name of the gem you wish to unpack.
Having done that… you’ll need to add something like this to your environment file:
[There’s some notes about this in the comments, which brings about a way of DRYing some of the requires… and seems to change the number of times something is loaded. There’s also more information here.] config.load_paths += %W( #{RAILS_ROOT}/vendor/???????/lib )
Then you can ‘require’ your gem in your controllers or libs etc.
All the “freezing” is about ensuring that the version that you’ve tested is the version your application uses in production. Much deployment peace is found here. I tell you three times.
config.load_pathsis for classes you want auto-required-and-loaded (and in turn reloaded). It's best just to add the vendor lib dirs to your standard ruby load path in environment.rb, e.g.$:.unshift File.join(RAILS_ROOT, "vendor/memoize-1.2.2/lib")You can then, for example,
require 'memoize'at the top of the model/controller/wateva that uses it, or once from environment.rb.I quite often just extract the gem's
tgz(which they nearly all have) directly into vendor, and not use rubygems at all.Tim Lucas
Daniel