Multiple rubygems versions, GEM_HOME and GEM_PATH

Installing rubygems is failrly easy and it’s great to have a package manager so you can forget about manually installing and upgrading the components you use. After installing a gem, you can require it from any ruby script and use it hassle-free. Well, given your ruby interpreter can find it.

When you install rubygems, a lot of default configuration is done behind the scenes. If you must see to believe, you can run

gem environment

do you believe me now?

Unless you are on windows, you have probably experienced already that gems can get installed in different locations. If using a superuser account, the global configuration will be used, but with a regular account gems install under your home directory.

If you are not careful about how you install your gems, or if you are using rake gems:install from regular accounts, you might end up installing the same version of a gem twice. That’s not only WET (not DRY, bear with me here) but it eats up your poor HD.

Things can get a lot worse than that. Suppose you are working with both JRuby and Ruby MRI. When you use rubygems from JRuby, it will try to use a different gem location by default. So, depending on how you are installing gems, you could have up to three different copies of exactly the same version.

And if you are on ubuntu and you upgrade from an old version of rubygems to the latest one —you will have to if you install Rails 2.3.4; if you are having problems you can read right here how to update it— you might be surprised that your gems are being installed *again*. The reason is under older versions the default location was “/var/lib/gems” and the latest one defaults to “/usr/lib/ruby/gems”.

Well, four different copies of ActiveRecord 2.3.4 are three and a half more copies than I wanted, mind you.

So.. how can we stop this gem install frenzy? Easy. Don’t use the defaults. Each of your installations is using default values, but they can be easily overridden with command line parameters or much more conveniently with environment variables.

Remember the title of this post? Can you see anything there that would make a good candidate for environment variables? That’s right, all the rubygems versions honor the GEM_HOME and GEM_PATH variables, so if they are set they will be used.

Depending on your OS, you can set these variables in different places. I’m on ubuntu and a bit lazy, so I chose the easiest, which is by adding this to my .bashrc file.

export GEM_HOME=/var/lib/gems/1.8
export GEM_PATH=/var/lib/gems/1.8

And now, no matter what I’m using: Ruby MRI, JRuby, or the latest rubygems, my already installed gems will be used, and the new ones will be put in the same place.

Saving the world is a hard job, but someone has to do it.

Actualizando rubygems a la versión 1.3.1

Hace un rato iba a instalar la última versión de merb, pero para instalar necesitaba tener al menos la versión 1.3.0 de rubygems, así que le he hecho el clásico

>gem update --system

con el siguiente resultado:

Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.1
ERROR: While executing gem ... (NameError)
undefined local variable or method `remote_gemspecs' for #


Sin embargo un segundo intento me decía esto

>gem update --system
Updating RubyGems
Nothing to update

(principio de la mínima sorpresa, ahem… )

Bien.. en teoría tengo la gema gem-update 1.3.1, de hecho un “gem list” parece que me dice que la tengo instalada, pero si hago un “gem –version” me dice que sigo en la 1.2.0

Por si acaso intento un “gem check” y un “gem pristine” sin éxito.. Y ahora qué? Ahora toca buscar en google, claramente.. tres enlaces después, parece que la solución comúnmente utilizada es la siguiente

>gem install rubygems-update
>update_rubygems

un minuto y tropecientas líneas de log después, ya puedes hacer un

>gem --version
1.3.1

oeeeeeeeeeee

p.s. en serio.. era necesario complicarlo *tanto* ?

searchwords: gem update rubygems-update update_rubygems merb