bueno, creo que encontré la respuesta a esta y otras dudas: 4.2 Using Explicit Versions http://docs.rubygems.org/read/chapter/4#page71
gemlock http://docs.rubygems.org/read/chapter/17#page99 y mirando los scripts instalados por rubygems en bin: $ cat rails #!/usr/bin/ruby1.8 # # This file was generated by RubyGems. # # The application 'rails' is installed as part of a gem, and # this file is here to facilitate running it. # require 'rubygems' version = "> 0" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end gem 'rails', version load 'rails' ------------------------------------------------------- $ cat merb #!/usr/bin/env ruby # # This file was generated by RubyGems. # # The application 'merb' is installed as part of a gem, and # this file is here to facilitate running it. # require 'rubygems' version = "> 0" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end gem 'merb', version load 'merb' y ver que está estandarizado el hacer una evaluación del primer parámetro como versión... $ rails -v Rails 2.0.2 $ rails _1.2.6_ -v Rails 1.2.6 $ merb -v merb 0.5.2 $ merb _0.5.1_ -v merb 0.5.1 (svn r1274) no es la idea de solución que tenía en mente, ya que hay que especificar como parámetro la versión, yo esperaba algo a nivel de rubygems que instalara en bin un tal rails-2.0.2 e hiciera un alias de rails -> rails-2.0.2 y que a través de gem manejara las opciones instaladas y su vigencia general. pero bueno habrá que hacer un par de scripts para emular eso a nivel gral y no tener que pasar el parámetro en cada lugar que llame a las gemas (IDE, consola, scripts, etc). Espero que les sea de utilidad. Saludos. Alejandro Vartabedian escribió: > Agrego que la idea inicial no es usar diferentes gem lib paths, sino > manejarse con lo instalado en el path por defecto. > > > Alejandro Vartabedian escribió: > >> Hola, >> Un par de preguntas: >> >> 1_ cual creen que es la mejor manera, argumentando los gustos ;-) , de >> manejar los paquetes/gems de ruby? >> Las opciones actuales son vía paquetes de la distro (apt-get install) o >> vía RubyGems (gem install) y muchos paquetes (mongrel, rails) son >> redundantes en ambos repositorios y cada opción tiene lo suyo, gem es >> más flexible a mi gusto por manejar múltiples versiones de la misma gema >> y ser independiente de lo disponible en la distro. >> Si bien hay que tomar recados en los paths de lo instalado en distros >> que siguen el FHS, en Debian (y derivados) por defecto en /var/lib/gems >> y cuyo directorio bin no se encuentra en el PATH por defecto. >> >> (sobre esta no he encontrado suficiente info) >> 2_ como activar/cambiar las versiones de las gemas a usar por el >> sistema/system-wide (consola, IDEs, etc), por ejemplo para probar código >> contra diferentes versiones de la misma gema (rails 1.2.6/2.0.2, merb, >> etc.) y no solo la última versión? (manejo el concepto de >> rails:freeze..., pero no es a lo que voy y tampoco me refiero a algo >> específico para rails) >> Por ejemplo, instalando vía rubygems rails 2.0.2 y luego rails 1.2.6 >> deja instalado a ambos y "vigente" a rails 2.0.2 (rails -v) y no he >> podido ver algún sistema de alternativas (ala Debian >> update-alternatives) o que defina aliases a los ejecutables de las >> diferentes versiones instaladas. >> >> Bueno tal vez sea mejor partirlo en 2 tópicos separados, aunque >> tienen mucha relación. >> >> Saludos. >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
