What are the benefits & drawbacks of installing things into the @global gemset in RVM?

3
votes

What are the benefits & drawbacks of installing things into the @global gemset in RVM?

Let's say I want to install different versions of rails on the same server. I then want the ability to install multiple ruby apps on the same server, with the least duplication of files to save on disk space. However, I still want to avoid dependency problems, gem conflict issues and other problems.

Let's also assume that each app has extra gems it needs that I only want in it's local project gemset.

Would I be better off:

  1. Installing both Rails 3 and Rails 2 gems into the @global gemset
    • ...And use project-local gemsets for their gems...
  2. Installing Rails 3 into a @rails3 gemset, and Rails 2 into a @rails2 set... then cloning for each project I need?
    For example:
    • rvm use ree@rails3 && rvm gemset export rails3.gems
    • rvm use ree@rails2 && rvm gemset export rails2.gems
    • rvm use --create ree@project1-on-rails3 && rvm gemset import rails3.gems
      • Install more project-local gems here...
    • rvm use --create ree@project2-on-rails2 && rvm gemset import rails2.gems
      • Install more project-local gems here...
  3. Something else entirely...
1
ruby-on-railsrubyrubygemsrvm

1 Answers

3
votes

NOTE: I wrote this whole response assuming that you are using Bundler to manage your gem dependencies. I realize that some people don't, and you didn't mention Bundler in your question. If you aren't using Bundler, I would point out that it probably is the best way to conserve disk space (only if you bundle install --system, though!). If you are using exported gemsets to manage dependencies, I think your scheme sounds reasonable, but I have no experience with it.

Both Rails 3, and Rails 2 with Bundler will set their load path appropriately such that they will not load any gems (or any versions of any gems) that are not in the Gemfile.lock. There's not really any way that I've experienced to have a "gem dependency problem" on the server. It is important that you run bundle install on your development machine whenever you modify the Gemfile, and that you check your Gemfile.lock into source control, as described on the Bundler homepage.

I spent some time digging into the use-cases of gemsets back in January. The reasons I found to use separate gemsets for each project were:

  1. Your shell environment is the same as your application environment (scripts run correctly without bundle exec).
  2. You can easily browse and grep through the source code of all your dependencies, by navigating to the gemset install directory.
  3. It prevents some reported ‘heisenbugs’, according to the author of RVM. I have experienced something like this where a gem executable wasn't available and bundle exec didn't seem to help.

I don't think any of these benefits are very compelling on the server, so if you are aiming to conserve disk space, I'm not sure why you would use gemsets at all.

Actually, the only reason I've used rvm at all on the server was because it was a convenient way to build ruby from source (we needed a version that wasn't available in the native package manager).