Reputation: 165
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?
Upvotes: 2
Views: 5546
Reputation: 176562
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.
Upvotes: 2
Reputation: 10546
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.
Upvotes: 5