For a couple weeks, I haven't been able to install any gems on my
MacBook Pro. I got so fed up with it that I eventually even wiped and
reinstalled the drive and OS ... and the problem hasn't gone away.
Here's what happens when I try to install a gem (with verbose debugger
output). Here I've used gemcutter, but this happens with every gem.
[code]
mbp:~ evan$ sudo gem install --verbose --debug gemcutter
Password:
Exception `NameError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 -
uninitialized constant Gem::Commands::InstallCommand
Exception `Gem::LoadError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find
RubyGem test-unit (>= 0)
Exception `Gem::LoadError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find
RubyGem sources (> 0.0.1)
Maybe it's using an "old version" of some of the libraries or what not?
If I were you I would reinstall ruby to some "special" location (like
$HOME/installs), then install rubygems into that instance and use it
from there.
HTH.
-r
I'm sitting here running Snow Leopard (and TextMate and PathFinder and
lots of other goodies you mention in your post), so I notice that you're
installing a second Ruby on top of the existing Ruby that's part of Snow
Leopard, and wondering whether this might be somehow confusing things.
Similarly you've apparently installed a second version of "gem", in
/usr/local/bin, when the standard location on Snow Leoard is /usr/bin
(there is already a "gem" there).
Of course it does look like your PATH is set in such a way that all of
that shouldn't matter - your ruby and your gem are evidently
overshadowing the standard versions successfully.
But since you've clearly nothing whatever to do with your time (insert
appropriate smiley here), I'm wondering what bad thing would happen if
you clean-installed Snow Leopard and then did NOT install this second
ruby. I'm betting that then you'd be able to install gems just fine. (Of
course you might still need the developer tools installed, in order to
get gcc, if a gem had native code to compile.)
I'm just musing out loud so I won't be offended if you tell me no, you
absolutely must have this other version of Ruby. m.
···
Evan Dorn <public@idahoev.com> wrote:
Here's what I've installed on this computer: 1) Fresh wipe of HD 2)
Install Snow Leopard 3) Install Apple Developer tools / xcode 4) Install
textmate and Path Finder 5) Install Ruby and Rubygems exactly as per
hivelogic:
For a couple weeks, I haven't been able to install any gems on my
MacBook Pro. I got so fed up with it that I eventually even wiped and
reinstalled the drive and OS ... and the problem hasn't gone away.
Here's what happens when I try to install a gem (with verbose debugger
output). Here I've used gemcutter, but this happens with every gem.
[code]
mbp:~ evan$ sudo gem install --verbose --debug gemcutter
Password:
Exception `NameError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 -
uninitialized constant Gem::Commands::InstallCommand
Exception `Gem::LoadError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find
RubyGem test-unit (>= 0)
Exception `Gem::LoadError' at
/usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find
RubyGem sources (> 0.0.1)
gem --debug install ruby-debug
Exception `NameError' at
/usr/lib/ruby/1.8/rubygems/command_manager.rb:161 - uninitialized
constant Gem::Commands::InstallCommand
Exception `Gem::LoadError' at /usr/lib/ruby/1.8/rubygems.rb:827 - Could
not find RubyGem test-unit (>= 0)
Exception `Gem::LoadError' at /usr/lib/ruby/1.8/rubygems.rb:827 - Could
not find RubyGem sources (> 0.0.1)
Exception `Errno::ENOENT' at /usr/lib/ruby/1.8/fileutils.rb:243 - No
such file or directory - /root/.gem/specs/gems.rubyforge.org%80
Exception `Errno::ENOENT' at /usr/lib/ruby/1.8/fileutils.rb:243 - No
such file or directory -
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem
Exception `Errno::ENOENT' at /usr/lib/ruby/1.8/fileutils.rb:243 - No
such file or directory -
/root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8
Exception `Errno::ENOENT' at /usr/lib/ruby/1.8/fileutils.rb:243 - No
such file or directory -
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem/specs
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem/specs/gems.rubyforge.org%80
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8
Exception `Errno::EEXIST' at /usr/lib/ruby/1.8/fileutils.rb:243 - File
exists - /root/.gem/specs/gems.rubyforge.org%80
Exception `#<Class:0xb650d708>' at /usr/lib/ruby/1.8/timeout.rb:60 -
execution expired
Exception `Timeout::Error' at /usr/lib/ruby/1.8/timeout.rb:74 -
execution expired
Exception `Gem::RemoteFetcher::FetchError' at
/usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:170 - timed out
(RubyGems.org | your community gem host)
Exception `Gem::RemoteFetcher::FetchError' at
/usr/lib/ruby/1.8/rubygems/spec_fetcher.rb:76 - timed out
(RubyGems.org | your community gem host)
I've managed to get some progress (I can actually install a gem) if I
specify --ignore-dependencies.
Interesting, I may have to try that.
I did in fact get gems working just by using Apple's pre-install Ruby
and Gems.
I couldn't do that with 10.5, because the pre-installed Ruby was 1.8.6
rather than 1.8.7, and I had compatibility problems with some of my
plugins under 1.8.6. But so far it's working for Snow Leopard.
It's frustrating, though, that building my own Ruby would cause such a
problem. It works just fine on on my desktop (Mac Pro) - it's only on
the laptop where it's been a problem.
Bret Weinraub wrote:
> I've managed to get some progress (I can actually install a gem) if I
> specify --ignore-dependencies.
Interesting, I may have to try that.
I did in fact get gems working just by using Apple's pre-install Ruby
and Gems.
Well, that's a good sign! I'm glad you tried my suggestion on this,
since at least it proves there's nothing wrong with the machine per se.
It must be something about that secondary Ruby installation you did.
I couldn't do that with 10.5, because the pre-installed Ruby was 1.8.6
rather than 1.8.7, and I had compatibility problems with some of my
plugins under 1.8.6. But so far it's working for Snow Leopard.
It's frustrating, though, that building my own Ruby would cause such a
problem. It works just fine on on my desktop (Mac Pro) - it's only on
the laptop where it's been a problem.
It is mysterious. I do have one other suggestion. I just found out about
RVM. This is has the tremendous advantage that it does all the heavy
lifting and sets up the *entire* Ruby environment for a secondary
version totally independently. Might be worth a try.
I've managed to get some progress (I can actually install a gem) if I
specify --ignore-dependencies.
Interesting, I may have to try that.
I did in fact get gems working just by using Apple's pre-install Ruby
and Gems.
I couldn't do that with 10.5, because the pre-installed Ruby was 1.8.6
rather than 1.8.7, and I had compatibility problems with some of my
plugins under 1.8.6. But so far it's working for Snow Leopard.
It's frustrating, though, that building my own Ruby would cause such a
problem. It works just fine on on my desktop (Mac Pro) - it's only on
the laptop where it's been a problem.
Although I never actually was able to put my finger on something that
fully did not work, I was able to resolve my problem via voodoo rites.
Basically this Ubuntu instance was running in Virtual Box on a Win7
machine. Now virtual box (like a lot of virtualization software)
generally defaults to NAT (network address translation) for network
connectivity.
Switching to "Bridged" on the interface pretty much cleared up the
problem; even though heavy network users like "apt-get" functioned just
fine. Whatever flakiness exists in the network only manifested itself
with "gem install". Bridged gives you a real address on your network,
instead of your packets being rewritten by the "host" machine.
I've seen of this with some VPN software; just will not function over a
NAT-ed interface. Switch to bridged, and its all good.
Probably should be a bug report for rubygems; it won't run off a NAT-ed
VM.
Basically this Ubuntu instance was running in Virtual Box on a Win7
machine. Now virtual box (like a lot of virtualization software)
generally defaults to NAT (network address translation) for network
connectivity.
Switching to "Bridged" on the interface pretty much cleared up the
problem; even though heavy network users like "apt-get" functioned just
fine. Whatever flakiness exists in the network only manifested itself
with "gem install". Bridged gives you a real address on your network,
instead of your packets being rewritten by the "host" machine.
I've seen of this with some VPN software; just will not function over a
NAT-ed interface. Switch to bridged, and its all good.
Probably should be a bug report for rubygems; it won't run off a NAT-ed
VM.
So, for me (and my students) who can't switch to bridged due to the
university's security policies, there basically is no solution? Wow.
This is killing me, new troubles every time I give this course. I
seriously must reconsider using Rails.
I suppose I could use aptitude to get an older Rails version, and do a
'gem freeze' for the application instead of upgrading Rails on the
server?
Basically this Ubuntu instance was running in Virtual Box on a Win7
machine. Now virtual box (like a lot of virtualization software)
generally defaults to NAT (network address translation) for network
connectivity.
Switching to "Bridged" on the interface pretty much cleared up the
problem; even though heavy network users like "apt-get" functioned just
fine. Whatever flakiness exists in the network only manifested itself
with "gem install". Bridged gives you a real address on your network,
instead of your packets being rewritten by the "host" machine.
I've seen of this with some VPN software; just will not function over a
NAT-ed interface. Switch to bridged, and its all good.
Probably should be a bug report for rubygems; it won't run off a NAT-ed
VM.
So, for me (and my students) who can't switch to bridged due to the
university's security policies, there basically is no solution? Wow.
This is killing me, new troubles every time I give this course. I
seriously must reconsider using Rails.
I suppose I could use aptitude to get an older Rails version, and do a
'gem freeze' for the application instead of upgrading Rails on the
server?
I blame myself for not filing a bug on rubyforge for this:
Basically this Ubuntu instance was running in Virtual Box on a Win7
machine. Now virtual box (like a lot of virtualization software)
generally defaults to NAT (network address translation) for network
connectivity.
Switching to "Bridged" on the interface pretty much cleared up the
problem; even though heavy network users like "apt-get" functioned just
fine. Whatever flakiness exists in the network only manifested itself
with "gem install". Bridged gives you a real address on your network,
instead of your packets being rewritten by the "host" machine.
I've seen of this with some VPN software; just will not function over a
NAT-ed interface. Switch to bridged, and its all good.
Probably should be a bug report for rubygems; it won't run off a NAT-ed
VM.
So, for me (and my students) who can't switch to bridged due to the
university's security policies, there basically is no solution? Wow.
This is killing me, new troubles every time I give this course. I
seriously must reconsider using Rails.
I suppose I could use aptitude to get an older Rails version, and do a
'gem freeze' for the application instead of upgrading Rails on the
server?
Here are some alternative options:
- yes use gem:freeze should allow you to get the app working somewhere
else, and then you can just pull the app onto the NAT-ed box.
- you can also install the gems from the source. It really isn't that
bad to do this, and you probably only need half a dozen gems for rails.
- you can push the whole thing into the cloud; I for one like linode :
For what its worth gem isn't the ONLY piece of software that won't run
on certain NAT-ed machines; I've experienced a similar problem with some
VPN software.
and if you could update the bug description (or post and I will attach)
your "gem env" and the debugging output of your "gem update" command.
I'm sure that's more than a few people who've been frustrated by this.