I've done some searching online and tried a few things with no luck.
I compiled Ruby 1.9.1 on a Mac that had previously been running 1.8.7.
How can I now either reinstall the gems, or point. Rubygems installs to the old location, but 1.9.1 is looking elsewhere. I've tried making a 1.9.1 (and 1.9) gems directory as a symlink to the old directory, but that doesn't seem to work. I've tried setting GEM_HOME and GEM_PATH but again no luck.
How can I find out where the current version of ruby is searching for gems at runtime, and alter it? And/or, how can I instruct rubygems to install gems where the latest version is looking for the gems.
You should either use a rvm, as was suggested, or install ruby 1.9.2 to /opt/ruby (configure --prefix=/opt/ruby --enable-shared) or /usr/local or /usr/local/ruby. Then put this path first in your PATH, before everything else. You'll have to reinstall gems anyway, as some of them are incompatible (built for 1.8.7).
It would be a good idea to install rvm and let it wrangle your Ruby versions and gems for you.
Also, you should probably upgrade to 1.9.2, as it's much more stable. 1.9.1 is basically a buggy development version of 1.9.2.
Related
I just installed Ruby 2.0.0 using rbenv and set it to the global ruby version for my system. Since 2.0 is compatible with 1.9.3, I tried to start up a Rails project with it, but got the following error. I did rbenv rehash after installing 2.0
The `rails' command exists in these Ruby versions:
1.9.3-p327
Does this mean that every gem I installed on my system with 1.9.3 has to be reinstalled if I wish to use it with 2.0?
As seen here:
You need to reinstall bundler for each version of Ruby you use. See Ruby versions where you have it installed:
rbenv whence bundle
See your current version:
rbenv version
Install bundler for that version, if missing:
gem install bundler
Yes. Rbenv (and RVM) have separate "gem home" directories for each installed version of Ruby. There may be ways to symlink certain directories to get them to share, but this will likely lead to problems, particularly with gems that include native C extensions, which may or may not compile and run cleanly in multiple versions.
If you have a Gemfile, easiest thing is to just bundle install again for Ruby 2.0, giving you duplicate copies of many gems and Ruby-2.0 compiled versions of any native gems.
Another solution to this is to copy (or reinstall) the gems from your previous version to the newly installed version. How to do that is answered in detail in this question, which has two scripts -- one to install from local cache, one to reinstall from the internet (mine).
I'm having trouble running a gem on system ruby -- I've done the install, and the gem runs when rvm runs 1.9.2, but doesn't run on rvm system, though that too is 1.9.2. The OS is OSX 10.6.8.
One importance difference seems to be GEM_HOME, as seen in rvm info. This is set for rvm 1.9.2, to values in ~/.gemrc, but not set for rvm system.
So at a guess, the system ruby isn't reading the .gemrc file.
Is there anyway to verify this?
How can I correct it?
The system ruby was installed from source.
The gem in question is compass, version 0.12.1. An install of 0.11.5 also failed.
Also, gem -v is 1.5.3. That's a rollback, I was using 1.8.24 but that too failed and I rolled back to a prior to see if that helped.
The system Ruby doesn't know about any gems you've installed in RVM managed Rubies, nor will it care about a .gemrc file.
The system Ruby stands alone, and for most purposes should be left as it was installed by Apple unless you reeeeeeally know why it's there and what it affects. Apple had their own reasons for installing Ruby and at least one app installed by Apple by default on a Mac OS machine requires it. We're free to use it, but deleting it will break that app, and updating it could cause problems that possibly won't surface immediately, so I think it's best to just ignore it.
If I need a system-wide Ruby for a Mac, I'd install it from source into /usr/local/bin, which is the appropriate place for a replacement. For my own development, I use RVM or rbenv, and let them install in my home directory, which is their default. That way I'm free to mess around to my heart's content, and even blow them away, without any chance of affecting the system.
By the way, the version of Ruby isn't important, it's what installed it and where it's installed.
I've been using the default system ruby version 1.8.7 without RVM for a few rails projects and have not run into any problems. I just recently installed RVM, and after running rvm requirements I get this output:
To use an RVM installed Ruby as default, instead of the system ruby:
rvm install 1.8.7 # installs patch 357: closest supported version
rvm system ; rvm gemset export system.gems ; rvm 1.8.7 ; rvm gemset import system.gems # migrate your gems
rvm alias create default 1.8.7
I believe what these commands do are to install the same gems that have already been installed using the system ruby under the RVM installed ruby.
My questions are, am I right in what these commands do? and if I am right, why is it important to do this, because if I wanted to use an RVM installed Ruby of a different version like 1.9.2, wouldn't it already separate gems in that version from the system's ruby?
The one thing that springs to mind is, if you use the system Ruby, you'll use it slightly differently that RVM's Rubies--for example, you'll likely need to use sudo to install gems. Furthermore, you won't be able to use many of RVM's features, like gemsets, with the system Ruby.
Well one reason I can think of is that you don't wanna worry about your system not working even if the system ruby gets updated.
My questions are, am I right in what these commands do?
You are right in what they do. The first command installs Ruby 1.8.7, the second command installs all the gems currently install on your system Ruby installation in the new RVM Ruby 1.8.7 installation, and the third command sets your default version of Ruby to be the RVM Ruby 1.8.7.
and if I am right, why is it important to do this, because if I wanted to use an RVM installed Ruby of a different version like 1.9.2, wouldn't it already separate gems in that version from the system's ruby?
The second command is actually more of about convenience than necessity. Yes, the gems install in the RVM 1.8.7 will be completely separate from the ones installed in the system version of Ruby; however, if you didn't run the second command, you're RVM 1.8.7 would start out with almost no gems (only the defaults). That means that you would need to go through and manually install the gems that you need to get your project up and running. Instead of doing that, the second command allows you to just install the same gems you've already installed in the system version of Ruby to the RVM 1.8.7 version—it doesn't migrate them, it just makes a copy of them. After the second command, there are two distinct sets of the exact same gems: one in the system Ruby and one in the RVM 1.8.7 Ruby. So, if you were to update gems in either of the Rubies, they would get updated, but the other version's gems would be unaffected.
Hope this helps answer your question.
I followed 2 different guides to install ruby on OSX and I think I messed some things up. Now that I know what I'm doing a bit more I have a feeling something is wrong. I'd like to 'start fresh' but i dont know what to remove safely (I dont mind re-installing everything. I have nothing super important)
I first used rvm and then decided i wanted to use homebrew. I uninstalled rails with rvm and then 'imploded' rvm. I then installed homebrew and then brew install rails 1.9.3
Although... when i run gem install xxx, all my gems seem to be in a weird path?
For instance, sinatra.rb is installed here:
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.3.1/lib
Notice it says 1.9.1, yet when I run
ruby -v
I get 1.9.3p0
and which ruby i get this
/usr/local/Cellar/ruby/1.9.3-p0/bin/ruby
If i do which [rails,git,mysql,whatever]
they all seem to point to Cellar.
as a sidenote, i have two versions of sinatra.rb on my computer... this is where the other one is (although the one I'm pretty sure it's not using).
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/sinatra-1.2.0/lib
kind of ridiculous...
I'm not sure whats going on here.
This is my path if that helps:
export LSCOLORS="GxGxBxDxCxEgEdxbxgxcxd"
export CLICOLOR=1
export PATH=/usr/local/Cellar/ruby/1.9.3-p0/bin:/usr/local/mysql-5.5.18-osx10.6-x86_64/bin:/usr/local/bin:$PATH
That's fine. You are using 1.9.3. The gems are installed under a 1.9.1 directory, to distinguish them from gems installed for 1.8.7 (some gems that work with the 1.9 series don't with 1.8, and vice-versa). 1.9.1 was the first released version of the 1.9 series.
I installed Ruby 1.9.2 on OS X Lion using brew install ruby and updated gem to 1.8.11 using gem update --system.
However, on my Rails 3 project, bundle is still using the Ruby 1.8 path (/System/Library/Frameworks/Ruby.framework/Versions/1.8/Ruby) to install new gems and fails with packages that require Ruby 1.9 (linecache19 in my case).
How do I let bundle know that I installed 1.9.2?
(I tried using RVM to installed Ruby and failed for some reason. The installer simply hand. I think the network connection was too slow or something)
Did you set a default Ruby with RVM or create a .rvmrc in your Rails project? If not, do so and then install the Bundler gem for the correct Ruby version before doing a Bundle install.
Update: I kinda misread your question before. For your system you use Homebrew's Ruby, make sure /usr/local/bin comes in your PATH before /usr/bin (where the system Ruby lives).
I retried rvm and it now it works like a charm. Apparently, this is the way to go.