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

ruby-talk
1

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:
      - http://gems.rubyforge.org/

Thanks in advance!

···

--
Alex Rice <agr@ncgr.org>
Software Engineer
National Center for Genome Resources (NCGR)
http://www.ncgr.org
(505)995-4457

2

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 25.12.2009 20:31, Alex Rice wrote:

--
Phillip Gawlowski
Wishing everyone a Merry Christmas, and happy holidays :slight_smile:

3

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,

···

On Fri, Dec 25, 2009 at 11:31 AM, Alex Rice <agr@ncgr.org> 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) ?

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan

4

Phillip Gawlowski 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?

···

--
Alex Rice <agr@ncgr.org>
Software Engineer
National Center for Genome Resources (NCGR)
http://www.ncgr.org
(505)995-4457

5

Hassan Schroeder 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.

···

--
Alex Rice <agr@ncgr.org>
Software Engineer
National Center for Genome Resources (NCGR)
http://www.ncgr.org
(505)995-4457

6

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:

···

On 27.12.2009 02:12, Alex Rice wrote:

Phillip Gawlowski 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?

--
Phillip Gawlowski

7

Phillip Gawlowski 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.

···

--
Posted via http://www.ruby-forum.com/\.