views:

1977

answers:

2

Let's say in a Rails app you have some gems that you use in your app (we'll call them "primary gems") and you have vendored them for portability.

Let's say that those "primary gems" also require gems of their own - we'll call these "secondary gems".

When you are setting up your environment.rb, you have to say:

config.gem 'primary-gem'

for any of the gems you are using directly.

But, do you also need to say . . .

config.gem 'secondary-gem'

even if you are not using that gem explicitly in your app?

Or is it simply enough to include the gem in your vendor/gems directory for it to get picked up by your app?

+4  A: 

At deploy time rails knows about your dependencies, so if you want to freeze your gems then you can run

rake gems:unpack:dependencies

to freeze them into the vendor directory.

At runtime however it's the gems job to load it's dependencies, and usually the gems do this, so a config.gem 'primary' should work.

SztupY
+2  A: 

No, you don't or at least you shouldn't. Each GEM specification should include it's own list of dependencies. When primary gem is installed, RubyGems automatically will install each gem dependency on cascade.

In other words, if A requires B that requires C+D, you only need to write

config.gem 'A'

When the command

gem install A

is run, RubyGems will resolve all the dependencies and install them. You can view all A dependencies running (from a Rails project)

rake gems

Sometimes, a GEM author may forget to include some GEM dependencies in the specification. In this case you should specify them in your environment.rb to force the application to install them. Off course, it's also a good idea to contact the GEM maintainer so that it can fix the problem.

Simone Carletti