OS X 10.6 has Rails 2.2.2 installed by default.
How to upgrade to Rails 2.3.8?
Since Rails 3 is out, is it possible to have multiple versions of Rails (like 2.3.8 and 3) installed on OS X?
(For example, I could be working on two Rails projects, one is Rails 2.x and the other is Rails 3.x).
Use rvm
RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems...
RVM allows users to deploy each project with its own completely self-contained and dedicated environment--from the specific version of ruby all the way down to the precise set of required gems to run the application. Having a precise set of gems also avoids the issue of version conflicts between projects, causing difficult-to-trace errors and hours of hair loss. With RVM, NO OTHER GEMS than those required are installed. This makes working with multiple complex applications where each has a long list of gem dependencies efficient. RVM allows us to easily test gem upgrades by switching to a new clean set of gems to test with while leaving our original set intact. It is flexible enough to even have a set of gems per environment or development branch--or even individual developer's taste...
I wouldn't bother with gemsets myself just do as other people have mentioned:
gem install -v=2.3.8 rails
and then to use:
rails _2.3.8_ new rails app
Note that this _versionnumber_ thing is a standard way of specifying a version of any rubygems installed executable.
Use
gem install -v=2.3.8 rails
where -v=[version number you want to install]
Then
list gem rails
In your config/environment.rb you can state which version of Rails you want to use.
To upgrade your OS version of the rails gem:
sudo gem install rails --version 2.3.8
While you're at it, you can also upgrade your OS rubygems system itself, overwriting the binary that OS X comes with. This might seem kind of hacky, but it's a stable thing that everyone does.
sudo gem install rubygems-update
sudo update_rubygems
Regarding managing rails versions in your projects, if your only needs are:
Specifying the version of rails that you want on a rails project
Specifying different versions of rails and/or other gems in each of multiple rails projects
Then rvm is overkill. The only thing you need, and what is also a complete and utter pleasure to work with, is Bundler. Bundler is like Software Update for your rails project. In fact, Rails 3 comes with Bundler by default, you just have to list the gems you need in Gemfile and it takes care of the rest. You don't need to worry about which versions of your gems are installed in the OS.
(You do however need the appropriate version of the rails gem installed in the OS in order to generate the rails project in the first place)
http://rubygems.org/
It's all you need =)
Related
Given we use a preferred flavour of a ruby version manager (RVM or Rbenv) the ruby gems are isolated per ruby version.
Let's say we want to work on multiple applications locally (they are completely separate applications) and we want to use the same ruby version and the same rails version how do we properly isolate them and their gems? Are gemsets the (only) answer here? I mean if I have 5 applications with the same ruby version and I keep adding gems on all 5 fronts it's just a matter of time when one of the applications is ok with the latest stable gem version while one of the apps will still need to roll on an older version of the same gem due to legacy dependency or whatnot. How do you guys avoid this timebomb?
What if we want to use the same ruby version on multiple apps but a different Rails version? Rails being 'just a gem' is the answer same as for the above?
Thanks.
I'd recommend to use:
rbenv to handle multiple ruby versions on the same machine
bundler to define the dependencies of each application
Make sure to push .ruby_version, Gemfile and Gemfile.lock to make sure every is using the appropriate version of each gem...
I'm a new Rails developer. I recently took a class on Rails and now I'm trying to make sure I'm growing in my skill by self-assigning projects that push me. One thing I'm trying to do now is use Radiant CMS to build a blog site. However, I'm running into some problems downloading the Radiant gem. Here's what I did:
When I first tried gem install radiant, it installed most of the required gems but then threw a warning (which I unfortunately did not save verbatim), which was along the lines of:
railties executable will overwrite rails executable. Overwrite? Y/n
Stupidly, I chose "Y". As soon as I did I tested my rails gem by writing rails new testproject and it failed. So I then re-ran gem install rails, told it to overwrite the "railties" executable, then ran gem uninstall radiant to get rid of the core radiant gem (although I do still have railties).
Now, my Rails gem is fixed, and I can create new Rails projects without an issue. However, I reinstalled the Radiant gem, and while it installed, it fails to create a project every time I run it.
I'm pretty sure I broke something, but I'm not terribly concerned about that. What I am concerned about is the fact that it seems that the Radiant gem doesn't really coexist well with the Rails gem, which leads me to my question:
Is there any way to create separate, self-contained ruby gem environments where the current Ruby version will only use the gems in the specified environment?
In essence, I'm looking for what rbenv does, but for collections of gems rather than Ruby versions.
Currently, I have Homebrew installed and I am using rbenv as my version manager. Everything I can find so far talks about managing gems on a project-by-project basis; I'm looking for something that will manage and keep separate the gems that create the projects in the first place. So, for example, environment_a contains rails and httparty while environment_b contains radiant and railties.
I'm not above completely obliterating rbenv and all of my gems and starting from scratch, either, so that's a possibility (and an advantage of being a noob).
You should check bundler, as it does exactly what you need.
Yes: rbenv-gemset
I think that it is better than RVM because it is less invasive.
I have been using rbenv and rbenv-gemset for about 2 years and find it easy to use. It makes it easy to encapsulate the Ruby and gemset in a project, run multiple Rubies and gemsets on one machine, and move a project to another machine.
You can use ruby-build to install other versions of Ruby. There is a trick to installing the latest versions of Ruby.
You may want to have a look at How do I ensure ruby gems are installed in right place to be executed by bundler? It has some relevant (and hopefully useful) info.
Yes, there is.
I think that it's called RVM.
Just like Chris Heald said, You can check more information about it # rvm.io/gemsets/basics
I'd recommend bundler for versioning gems although both RVM and rbenv also have this functionality.
You asked: "Is there any way to create separate, self-contained ruby gem environments where the current Ruby version will only use the gems in the specified environment?"
The best way to do it with rvm is entering your project's directory and then run:
rvm use ruby-x.y.z#your_project_name --ruby-version --create
where x.y.z is your Ruby version for that project, previously installed with rvm install x.y.z
For example, to use the newest Ruby version with a project named acme you would use
rvm install 2.3.1
and then
rvm use ruby-2.3.1#acme --ruby-version --create
This command would create two files in the projects directoty: .ruby-version and .ruby-gemset.
The file .ruby-version would contain just the version number. And the file .ruby-gemset would contain only the name off the gemset, the same name of your project (acme).
It happens that rvm is smart enough to check for these files and use the gemset specified, which will be located at ~/.rvm/gems/ruby-2.3.1#acme and your gems will be located at ~/.rvm/gems/ruby-2.3.1#acme/gems.
Some points:
1) Using your project's name as the gemset name is NOT mandatory. You may use anything you like. It's kind of a standard using project's name, but not mandatory.
2) rbenv probably has a way to do the same, but I don't use rbenv and really don't know how to do that.
Hope this answer helps.
I currently have several Rails applications running version 3.2.13 that use Ruby 1.9.3. I plan to eventually upgrade my current applications to Rails 4.0 then upgrade Ruby to 2.0. I need to time the conversion to Ruby 2.0 carefully since from my understanding Phusion Passenger will only handle one version of Ruby without some nose bleeding solutions which I do not plan to attempt to implement at this point.
I currently use one gemset for all my Rails applications. I would like to convert my Rails applications one by one from 3.2.13 to the current version of Rails 4.0 at some point. When I have tried to update one of my applications to a newer version of Rails I was told I had to do a update rails command.
What I want to do is to be able to run some of my applications using Rails 3.2.13 and others using Rails 4.0 until I am sure they will all run properly under Rails 4.0. Once I do this I will review the differences between Ruby 1.9.3 (if any) and upgrade all of them to use Rails 2.0. At this point I understand that I would just create the gemset for 2.0.0 or whatever the latest stable version of Ruby 2 is.
I have done web searches and checked the RVM website. I understand how the gemsets are assigned to the version of Ruby you want to run. However I'm not seeing anything about using gemsets with the same version of Ruby but using different versions of Rails or other combinations of gems on the same machine for different applications. Can this be done?
Any help would be appreciated.
Take a closer look! ;)
First, create a new gemset with a name corresponding to your project
https://rvm.io/gemsets/creating/
ex: rvm gemset create project_name
Then create/edit .rvmrc file in project directory: rvm use 1.9.3#project_name
One pitfall is that if you execute following commands
cd some_project
cd ../other_project
and other_project doesn't have gemset specified you'll stay in some_project gemset. To avoid that you can create .rvmrc file with default gemset in your "projects" directory (if you have one)
Project Folder
|___Gemfile
|__.ruby-gemset
|__.ruby-version
Gemfile with all the required gems mention in your project folder
.ruby-gemset should have gem set name like sample-gemset
.ruby-version file should have specific ruby version (e.g 2.0)
rvm gemset list
it will show gem set created with sample-gemset and do the
bundle install
which will install all the specific gems for this project under sample-gemset,
same you can do for other project to create other gem set, in this way you can maintain different rails/gems and ruby version for different projects with rvm.
Your Gemfile.lock nails down which version of every gem you use - you don't need to worry about gemsets.
bundle install will always install the correct versions and your app will always use the versions in Gemfile.lock, even if there are other versions floating around
I'm trying to deploy my Rails 3.0.1 application which works with Ruby 1.9.2.
However, I noticed that Rails 1.8.7 is installed on the server.
What steps should I take to install Ruby 1.9.2 on the server, and force my application to use it ?
I use Apache and Passenger.
I would recommend installing RVM and using that to set the version of Ruby that you want on the server.
Here's a rundown of its advantages in a production environment:
RVM allows users to deploy each
project with its own completely
self-contained and dedicated
environment--from the specific version
of ruby all the way down to the
precise set of required gems to run
the application. Having a precise set
of gems also avoids the issue of
version conflicts between projects,
causing difficult-to-trace errors and
hours of hair loss. With RVM, NO OTHER
GEMS than those required are
installed. This makes working with
multiple complex applications where
each has a long list of gem
dependencies efficient. RVM allows us
to easily test gem upgrades by
switching to a new clean set of gems
to test with while leaving our
original set intact. It is flexible
enough to even have a set of gems per
environment or development branch--or
even individual developer's taste!
It's very easy to setup and use, especially compared to managing the Ruby versions yourself. I've done both and I prefer RVM much more now. Once you have RVM installed, using Ruby 1.9.2 is as easy as:
rvm install 1.9.2
rvm use 1.9.2
And then you can check which version of Ruby your production environment is using with:
ruby -v
Assuming you use Apache, reinstall Passenger with
$ passenger-install-apache2-module
while having Ruby 1.9.2 active. If you use RVM just type rvm use 1.9.2 to make that version of Ruby active. Follow the on-screen instructions for how to modify your httpd.conf.
I'm working on two different rails installations for two different projects. They are on different versions of rails. Here's what I have installed:
gem list --local | grep rails
shows that I have this installed:
rails (3.0.0.beta4, 2.3.5)
When I run a command to do a deployment for the app that uses 2.3.5, I get the following error:
Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your
RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do
have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
It's not finding the correct rails version, even though I have it installed. What are good short- and longer-term solutions for this problem?
I suggest you RVM. It allow you to have different ruby/gems versions on the same machine.
The long term solution is to look into rvm, especially the gemset feature makes it really easy to keep separate versions of gems and even ruby versions for different projects.
A short trem solution may be to add the the following line to your boot.rb file, somewhere before rails is required:
gem rails, "2.3.5"
This loads the right version of the gem, otherwise gem will think you want the latest version.
As others have noted, rvm is one way to solve this problem. The other is to use bundler, which involves some setup in your application and potentially requiring you to use 'bundle exec command' everywhere you want to run conflicting versions of a command (eg cucumber)