[Rubygems-developers] Installing Rubygems in User's Local Directory to fix Gem on Memory-Limited Systems

Randy Parker randy.j.parker at gmail.com
Fri Jun 8 14:18:06 EDT 2007


Following the naive "gem install rails", I tried Jim's incremental update:

gem list -r -B 1000000

this took 8 minutes on Joyent's dual 3GHz AMD running a load average of 0.4,
and sucking only 1.8% of the cpu.  More importantly, it completed
successfully, and a subsequent "gem install rails" also worked!!

On 6/8/07, Randy Parker <randy.j.parker at gmail.com> wrote:
>
> On 6/7/07, Eric Hodel <drbrain at segment7.net> wrote:
> >
> > Please don't top post.
> >
> > On Jun 7, 2007, at 12:30, Randy Parker wrote:
> >
> > > Which bug is not fixed yet?  I see that [rubygems #8470] is still
> > > open on   http://rubyforge.org/tracker/ ?
> > > atid=575&group_id=126&func=browse
> > >
> > > But my understanding of #8470 is that the the local
> > > dir is not _automatically_ used for installation.
> >
> > There may be two bugs, but they both seem to be in the same category.
> >
> > > Do you mean that the most recent note posted to the bug
> > > report, which proposes a workaround by re-running
> > > the install sequence
> > >
> > >   ruby setup.rb config --prefix=$GEM_HOME
> > >   ruby setup.rb setup
> > >   ruby setup.rb install
> > >
> > > Is also known NOT to work?  (it ain't just me?)
> >
> > I've not tried it, but I'm going to take your word for it.  I'm a bit
> > busy right now to investigate in detail.
> >
> > Can you poke around in setup.rb to see if its ignoring --prefix?
> >
> > > If that is true, then is it accurate to say that there is no way
> > > to run "gem update --system" for a "non-standard installation
> > > directory"
> > > (that is, one that doesn't require root access, as described by
> > > http://rubygems.org/read/chapter/15#page101 )
> > >
> > > If there is no workaround, then because "gem install" / "gem
> > > update" require rubygems-update-0.9.4.2 to run on memory-
> > > constrained hosting containers,
> > > and the only way to install it is with root permission, then it
> > > must be that
> > > nobody can use "gem" unless they have a dedicated system (or a hosting
> > > container that is as big as a dedicated system).
> > >
> > > Surely I'm missing something?
> >
> > You can install your own ruby in your homedir, then it'll work.
> >
> > Right now it appears to be using Ruby's prefix over the one you
> > want.  If you have your own ruby, you'll be able to write to where
> > setup.rb is trying to put things.
> >
>
>
> I did not fix setup.rb.  Instead, I installed ruby in ~/ruby.
>
> The Joyent / Textdrive shared host "kientz" is supposed to restrict memory
> in my Solaris container to 100MB.  It looks like that is not enough to use
> gem.
>
> My other shared hosting accounts are Textdrive's FreeBSD, restricted to
> 48MB, and Site5's Linux, restricted to 50MB.  I think it is safe to assume
> that they will continue to fail with 0.9.4.2 as well.
>
> [kientz:~/ruby] randy$ gem env
> RubyGems Environment:
>   - VERSION: 0.9.4.2 (0.9.4.2)
>   - INSTALLATION DIRECTORY: /users/home/randy/ruby/lib/ruby/gems/1.8
>   - GEM PATH:
>      - /users/home/randy/ruby/lib/ruby
>      - /users/home/randy/ruby/lib/site_ruby/1.8
>      - /users/home/randy/ruby/lib/ruby/gems/1.8
>   - REMOTE SOURCES:
>      - http://gems.rubyforge.org
>
>
> [kientz:~/ruby] randy$ gem list
>
> *** LOCAL GEMS ***
>
> rubygems-update (0.9.4.2)
>     RubyGems Update GEM
>
> sources (0.0.1)
>     This package provides download sources for remote gem installation
>
>
> [kientz:~/ruby] randy$ gem install rails
> Bulk updating Gem source index for: http://gems.rubyforge.org
> /users/home/randy/ruby/lib/ruby/1.8/yaml.rb:133:in `node_import': failed
> to allocate memory (NoMemoryError)
>         from /users/home/randy/ruby/lib/ruby/1.8/yaml.rb:133:in `load'
>         from /users/home/randy/ruby/lib/ruby/1.8/yaml.rb:133:in `load'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:272:in
> `convert_specs'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:295:in
> `fetch_bulk_index'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:252:in
> `update'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:26:in
> `refresh'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:111:in
> `refresh'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:104:in
> `each'
>          ... 11 levels...
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:121:in
> `process_args'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:92:in
> `run'
>         from
> /users/home/randy/ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:31:in
> `run'
>         from /users/home/randy/ruby/bin/gem:23
>
> The memory allocation failure is independent of the target gem size, it
> results from decompressing the gem index yaml file.  (I realize the rubygems
> developers already know this; I'm just pointing this out to anyone else who
> might suggest I retry with a smaller gem target than 'rails')
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070608/65823154/attachment-0001.html 


More information about the Rubygems-developers mailing list