Question about multiple ruby + gems installations for dev/test/prod

Hi All, I am pretty new to Ruby, and googled quite a bit about the gem
utility, but am kind of stuck. I need some advice about maintaining good
separation between ruby installs and gem directories.

In this project we have Ruby installs for dev, test and prod. The idea
is we can test different versions of ruby, rails, and different gems.
Then when it’s getting promoted from test to prod, just cp -R the ruby
directory and all it’s gems from test to prod. Nice idea except the gems
paths are all fouled up now.

Question: How does the gem script actually figure out it’s environment
and where it’s gems are? Is there a config file somewhere? I can’t find
it if there is.

Question: What is the best practice for this kind of situation
(test/dev/prod environments for ruby) ?

I am aware of the GEM_PATH and GEM_HOME environment variables. They are
not currently set. I have lots of shell scripts pointing at this ruby
install, and don’t want to have to add GEM_PATH and GEM_HOME to all of
those shells scripts. However if that’s the only way, then I guess I can
live with that.

I am also aware of the sandbox gem but do not want to make this overly
complicated. It should be possible to do this without additional gem
dependencies.

$ which ruby
/home/grindstone/prod/ruby/current/bin/ruby # prod is good

$ which gem
/home/grindstone/prod/ruby/current/bin/gem # prod is good

$ echo $GEM_PATH # not set
$ echo $GEM_HOME # not set

gem env bad! gem seems looking at test, not prod…

$ gem env
RubyGems Environment:

  • RUBYGEMS VERSION: 1.3.1
  • RUBY VERSION: 1.9.1 (2009-05-12 patchlevel 129) [x86_64-linux]
  • INSTALLATION DIRECTORY:
    /home/grindstone/test/ruby/1.9.1-p129/lib/ruby/gems/1.9.1
  • RUBY EXECUTABLE: /home/grindstone/test/ruby/1.9.1-p129/bin/ruby
  • EXECUTABLE DIRECTORY: /home/grindstone/test/ruby/1.9.1-p129/bin
  • RUBYGEMS PLATFORMS:
    • ruby
    • x86_64-linux
  • GEM PATHS:
    • /home/grindstone/test/ruby/1.9.1-p129/lib/ruby/gems/1.9.1
    • /home/agr/.gem/ruby/1.9.1
  • GEM CONFIGURATION:
    • :update_sources => true
    • :verbose => true
    • :benchmark => false
    • :backtrace => false
    • :bulk_threshold => 1000
  • REMOTE SOURCES:

Thanks in advance!

On 25.12.2009 20:31, Alex R. wrote:

Hi All, I am pretty new to Ruby, and googled quite a bit about the gem
utility, but am kind of stuck. I need some advice about maintaining good
separation between ruby installs and gem directories.

http://rvm.beginrescueend.com/
Seems like that’s what RVM was intended for. :slight_smile:

In this project we have Ruby installs for dev, test and prod. The idea
is we can test different versions of ruby, rails, and different gems.
Then when it’s getting promoted from test to prod, just cp -R the ruby
directory and all it’s gems from test to prod. Nice idea except the gems
paths are all fouled up now.

Question: How does the gem script actually figure out it’s environment
and where it’s gems are? Is there a config file somewhere? I can’t find
it if there is.

While I’m not aware of Rubygem’s internals, I know that it does look at
“.gemrc” in the home directory of a user first, to parse variables,
including GEM_HOME and GEM_PATH.

Coupled with RVM, this should enable you to separate your dev/test/prod
environments on the same machine.

I am aware of the GEM_PATH and GEM_HOME environment variables. They are
not currently set. I have lots of shell scripts pointing at this ruby
install, and don’t want to have to add GEM_PATH and GEM_HOME to all of
those shells scripts. However if that’s the only way, then I guess I can
live with that.

See “.gemrc” in Rubygem’s manual:
http://docs.rubygems.org/read/chapter/11

That should enable you to setup a .gemrc-dev, a .gemrc-testing, and a
.gemrc-production with ease.

Alternatively, you could also use rake rails:gem:freeze to, well, freeze
the gems your Rails app uses.

On Fri, Dec 25, 2009 at 11:31 AM, Alex R. [email protected] wrote:

I need some advice about maintaining good
separation between ruby installs and gem directories.

Question: What is the best practice for this kind of situation
(test/dev/prod environments for ruby) ?

Have you considered virtualization?

It’s so easy to create a single-purpose image and then you have no
worries about path confusion. As you need to test new releases you
just create a new clean image, install and go.

FWIW,

Hassan S. wrote:

Have you considered virtualization?

It’s so easy to create a single-purpose image and then you have no
worries about path confusion. As you need to test new releases you
just create a new clean image, install and go.

Thanks for the suggestion- I have no experience with virtualization of
servers. There are also lot of NFS and SMB filesystems involved and I am
not sure it would be so easy to create a working image. I could be wrong
though.

Phillip G. wrote:

http://rvm.beginrescueend.com/
Seems like that’s what RVM was intended for. :slight_smile:

See “.gemrc” in Rubygem’s manual: http://docs.rubygems.org/read/chapter/11

That should enable you to setup a .gemrc-dev, a .gemrc-testing, and a
.gemrc-production with ease.

Alternatively, you could also use rake rails:gem:freeze to, well, freeze
the gems your Rails app uses.

Thanks- very good suggestions.

I still am puzzled as to why my prod environment is using gems from the
test environment. There must be a dotfile or config file somewhere in
the gem directory. Does anyknow know where the gem path is actualy
stored in the ruby install, if it’s not in .gemrc and not in GEM_PATH
and GEM_HOM?

On 27.12.2009 02:12, Alex R. wrote:

Phillip G. wrote:

I still am puzzled as to why my prod environment is using gems from the
test environment. There must be a dotfile or config file somewhere in
the gem directory. Does anyknow know where the gem path is actualy
stored in the ruby install, if it’s not in .gemrc and not in GEM_PATH
and GEM_HOM?

I hacked up a quick script (after digging through rubygem’s sources):
PS C:\Scripts> ruby .\gemconfig.rb
sitedir: C:/Ruby/lib/ruby/site_ruby
bindir: C:/Ruby/bin
sitelibdir: C:/Ruby/lib/ruby/site_ruby/1.8
datadir: C:/Ruby/share
vendordir:
EXEEXT: .exe
libdir: C:/Ruby/lib
vendorlibdir:
ruby_install_name: ruby
RUBY_SO_NAME: msvcrt-ruby18
ruby_version: 1.8
arch: i386-mingw32
PS C:\Scripts> cat .\gemconfig.rb
require “rubygems”
Gem::ConfigMap.each do |config,value|
puts “#{config}: #{value}”
end
PS C:\Scripts>

The path seems to be built on runtime (I don’t have a .gemrc defined in
my home dir).

So, this raises the question, if your production environment is isolated
from the development and testing environments, and if so, how?
(Mind, this is a question out of curiosity, to get to the root of the
problem :slight_smile:

Phillip G. wrote:

The path seems to be built on runtime (I don’t have a .gemrc defined in
my home dir).

The root of my confusion, is as follows. In retrospect it’s not
surprising though. I have everything straightened out now.

If you run (in Unix - maybe no equivalent in Windows )
strings ruby | grep lib
You can see your lib directories are compiled into the binary.

So gem uses that path appends ruby/gems/[version] and that becomes the
default GEM_PATH.

It adds to the gem path if there is a ~/.gem directory with stuff in it.
.gemrc and GEM_PATH environment variables may further change or override
the gem paths.

Summary, it’s a no-no to move around a ruby install directory like I was
doing, because the lib paths will get broken.