5 Comments

1. 

   Randy Schmidt says:

   Hi! I’m working on setting this up for an application and I am running into an issue with activating gems from github that may have a different lib than the name of the gem (ie mislav-will_paginate). I’ve been digging through the documentation and source code trying to figure out how to specify them correctly and have fun into a dead-end. Any guidance about where I can look would be greatly appreciated. Thanks!

   August 28, 2009 at 12:44 am

2. 

   Chad Woolley says:

   @Randy,

   I think you might be confusing ‘activating’ a gem with ‘requiring’ a library from that gem. ‘Activation’ means calling the rubygems ‘gem’ method to put all of the gem’s files on the Ruby load path ($:). The ‘[GemInstaller.autogem](http://geminstaller.rubyforge.org/documentation/tutorials.html#using_the_autogem_option_to_automatically_require_gems)’ method does this automatically for all the gems in your geminstaller.yml file (hence the name). ‘Requiring’ means calling the ruby require method to read/parse/evaluate the gem’s main entry point file (which should already be on the load path via activation).

   The ‘config.gem’ method in Rails handles this problem by having a ‘:lib’ option, but in GemInstaller I just expect you to require the files yourself (usually in your environment.rb file). I don’t believe you should mix activation with requiring, because that can lead to unknowingly requiring with incorrect versions or incorrect order… But I digress…

   Anyway, to fix your problem, you need to add the following to your rails config/environment.rb (or some other early entry point to your app, if it is not a rails app):

   require ‘will_paginate’

   I like to think of it as three steps that are required to use a RubyGem:

   1. Install the gem ([GemInstaller.install or just 'geminstaller' from the command line](http://geminstaller.rubyforge.org/documentation/index.html))
   2. Activate the gem ([GemInstaller.autogem](http://geminstaller.rubyforge.org/documentation/tutorials.html#using_the_autogem_option_to_automatically_require_gems))
   3. Require the appropriate file from the gem. Usually this is the same as the gem name, but sometimes it isn’t, as in the case of github gems which have the userid prefixed to the gem name.

   For further reading, see [Eric Hodel's post on solution to this problem](http://blog.segment7.net/articles/2009/02/04/a-rubygems-github-proposal).

   Hope this helps, let me know if you have more questions. Thanks for your interest in GemInstaller!

   – Chad

   August 28, 2009 at 10:20 pm

3. 

   Randy Schmidt says:

   This is a huge help! Thank you!

   August 29, 2009 at 7:33 am

4. 

   nicholas a. evans says:

   Chad, I looked through the documentation, but I couldn’t find any guidance on what to do for “development” dependencies. E.g. “rspec”, “shoulda”, “cucumber”, or “factory_girl”, etc. These are the gems that don’t need to be installed to run the app or run the production-use rake tasks (e.g. rake db:migrate), and arguably should not be installed in production, but do need to be installed in order to run the tests or load certain development/test specific rake tasks.

   The common suggestion for “config.gem” is to stick those tasks into your “config/environments/test.rb”, but that just aggravates the chicken/egg problem that already exists with “config.gem”.

   I’m currently using erb in the geminstaller.yml to check for ENV["DEVELOPMENT"], putting guard clauses around particular rake files (e.g. the ones that use rspec or rcov’s rake support) to skip loading of the file if the gem hasn’t been loaded, and then telling developers to use “(cd config; DEVELOPMENT=true geminstaller)”.

   Is there a better way?

   September 4, 2009 at 10:43 am

5. 

   Chad Woolley says:

   @nick,

   If you care about not loading dev/test dependencies in other environments, I don’t know of a better way.

   However, I’d say the simplest solution is to not care about this, and install/activate all dependencies in all environments. If you think about it, you want your test environment to be as close as possible to your production environment, so the same bugs will manifest the same way in both places. So why not just let everything load the same in all environments, and not worry about it?

   Ideally, test libraries should have no impact on your code when it runs in production. In that case, you are fine by still loading them in a prod environment. If, for some reason (probably a bad one, keep reading), your test libraries DO have some impact on non-test code, then you probably still want your code to behave the same way under test as it does in production.

   If you have all of your gem dependencies and versions specified properly (which is admittedly hard), you shouldn’t worry about having versions installed which you are not going to use.

   Finally, remember the difference between *activating* a gem (putting it on the load path) and *requiring* a file from a gem (parsing/evaluating the ruby code in a file). If you never require a file from the gem, then there *SHOULD* be no side effect to having it activated. This is usually easily handled by putting your test require statements in your test.rb environment file or test helper. However, since gem activation automatically puts the gem’s /lib dir on the load path, it is possible to inadvertently require the wrong files from badly packaged gems which don’t have good namespacing and dump stuff other than a single file in the lib directory. Although, a problem like this would probably be obvious long before it ever made it to production.

   The only arguments against the install-and-activate-everything-everywhere approach that I can think of are:

   1. You don’t want to mask any interactions that your test libraries have on your non-test code. This is a good goal, but you are only going to find it through manual QA on your staging or production environment (or through any associated bugs).

   2. The test libraries cause some performance degradation simply by being loaded.

   Again, both of these should only be problems if you have actually required something you didn’t intend to, which shouldn’t be the case if you only require test libraries in your test environment, test helper, and other non-production files.

   Hope this helps,
   – Chad

   P.S. Check out Bundler: [http://github.com/wycats/bundler/tree/master](http://github.com/wycats/bundler/tree/master)

   September 4, 2009 at 6:44 pm