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.
Related
Have had 1.9.3p194 (RubyInstaller) with Ruby on Rails and all kinds of Gems installed on my WinXP. Now I want to update the whole setup.
Updating RoR (to 4.0.0) and gems was easy: gem update rails, gem update --system, gem update.
But how do I do that with Ruby? Is there an easy way to update the installation?
If not, and I have to install the fresh package, then how do I do it with little hassle?
I have downloaded the fresh 2.0 RubyInstaller. I have read that I shouldn't install this new Ruby version in the same directory as my old Ruby version (c:\programs\Ruby) that's why I chose a c:\programs\Ruby200 directory. During the installation I clicked on every additional setting, including the "include new directory in the PATH variable" type of choice. But now when I type ruby -v I still get 1.9.3p194 and the new directory is absent from PATH (I haven't rebooted, so maybe this has something to do with it).
So how should I really install the new version? Should I simply change the old PATH to the new one? Or should I instead only add the new one without removing the old path (so there will be some kind of advantage of having both 1.9.3 and 2.0)? Or should I simply delete both installations and install 2.0 from the start?
How do I easily transfer the gems (or the list of them, so the gem update could handle the installation/updating) from my old installation to the new one?
I am using JetBrains RubyMine 5.4 editor, and would like to know if I need to do something there as well (for both the new and the existing projects).
Like many POSIX users, I rely on rvm and bundler to manage ruby versions & gemsets. Unfortunately, rvm is not available on windows. Although I haven't tried it personally, it looks like pik is a viable windows alternative. I would recommend checking that out.
You should also definitely look into bundler if you're not already using it; since bundler is just a gem, it should be platform independent.
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
TL;DR
Don't bother with gemsets; multiple versions of a gem may be installed concurrently.
When necessary, specify which version to execute using $ gem-based-binary _version_ args notation.
Use bundle exec when you have a Gemfile specifying the version.
gem install rails -v 3.2.13
rails _3.2.13_ new Project2
cd Project2
bundle exec rails server
UPDATE: 2015-06-04
I wrote this question three years ago. Partly, it was based on a false assumption, and partly the situation has changed since then. With appreciation to #indirect for his original answer, I want to call attention to #kelvin's newer (less upvoted) answer, summarized above.
My false assumption: Only a single version of a gem could be installed at a time, hence the need for gemsets to isolate the namespace. Not true. Multiple versions of a gem may be installed concurrently. The most recent one will be used when invoked from a command line, unless you have a Gemfile specifying the version constraints and invoke the command via bundle exec, or specify the version as its first argument.
See also How can I call an older version of a gem from the commandline? re: the underscore-version notation.
Original question:
I have multiple projects going on using different versions of Rails. I have a workflow (described below) for creating projects using specific versions of rails, and keeping the projects isolated from each other. I'd like to experiment with other workflows, in particular, using rbenv instead of RVM, but it's not clear how to do so.
QUESTION: What is the best current practice for creating multiple rails projects, each using a different version of rails, when making use of rbenv and bundler, as opposed to rbenv-gemset or rvm?
USE CASE: I have two rails projects, called ProjectA and ProjectB. ProjectA is developed using one version of rails ("RailsA"), whereas ProjectB uses a different version ("RailsB"). How do I manage having both versions installed?
THE GEMSETS APPROACH: When I first started with Rails development, I used RVM. In addition to supporting multiple, concurrent installations of ruby, RVM supports having multiple Named Gem Sets. Each project has its own independent collection of gems (including rails itself) called a gemset:
rvm gemset create RailsA
rvm gemset use RailsA
# RailsA. Note: My question is not version-specific.
gem install rails --version 3.0
rails new ProjectA
cd ProjectA
rvm --rvmrc use `rvm current`
vi Gemfile
bundle install
cd ..
## Now do the same for ProjectB
rvm gemset create RailsB
rvm gemset use RailsB
gem install rails --version 3.2
rails new ProjectB
cd ProjectB
rvm --rvmrc use `rvm current`
vi Gemfile
bundle install
Note: The very creation of the project folders should be done (IMHO) by a rails new command using the desired version of rails, since the skeleton files change from version to version. (Perhaps I should revisit this premise?)
THE BUNDLER APPROACH: I've been playing with using rbenv instead of RVM, but I don't understand the workflow as clearly. In the README.md, Sam Stephenson writes that "rbenv does not ... manage gemsets. Bundler is a better way to manage application dependencies." There is a plugin (rbenv-gemset) for getting the same results as rvm's gemsets, but Sam clearly favors using Bundler instead. Unfortunately, he doesn't elaborate on what the workflow would look like. Even the Bundler website doesn't explicitly connect all the dots of how to isolate one project from another. Several blogs and gists come to the rescue, suggesting the following ~/.bundle/config file:
---
BUNDLE_PATH: vendor/bundle
(BTW, I'm not sure what the "---" is about. The docs make no mention of it and it doesn't seem to make a difference.)
This effectively gives each rails project its own gemset, storing the gems in ProjectX/vendor/bundle/. In fact, rails itself will be (re-)installed there, making the project completely independent of the rest of my environment, once I run bundle install.
But the elephant in the room is the chicken-and-egg problem of creating the rails project folder in the first place!! In order to create the ProjectA folder using RailsA, I need to install rails (and its numerous dependencies) first. But when I want to create ProjectB, I must then switch to using RailsB. Without gemsets, I must do some serious upgrading/downgrading. Not cool.
A possible solution is simply not to worry about what version of rails I use to create the ProjectX folder. If I then use rails 3.0 to create a 3.2 project, I could just manually create the app/assets tree. But that just irks me. Ain't there a better way?
Most people solve this by installing the rails gem first via gem install rails. If you refuse to do that for some reason, you can opt out of the automatic bundling that Rails attempts to do for you. This will work completely regardless of your ruby management system.
mkdir myapp
cd myapp
echo "source :rubygems" > Gemfile
echo "gem 'rails', '3.2.2'" >> Gemfile
bundle install --path vendor/bundle
bundle exec rails new . --skip-bundle
When prompted, type "y" to replace your Gemfile with the default Rails one (or not, as you prefer). Then, once it's done:
bundle install
You're done, and you have boostrapped a new rails app with the version of your choice without installing the rails gem into rubygems.
Suppose you have rails 3.1.0 installed, but you want to create a new project using rails 3.2.13 which is not installed.
Let's say you want the new project to be in ~/projects/Project2.
gem install rails -v 3.2.13
cd ~/projects
rails _3.2.13_ new Project2
This will create the Gemfile for you, locked to the version of rails you specified on the command-line.
I deliberately omitted the idea of keeping a separate copy of gems for the new project, because that goes against the Bundler philosophy, which is to have all gems installed in one place. When you run rails, Bundler will pick the correct gem versions automatically from that central location. That means a project can share gems instead of installing a fresh copy for itself. (Note, however that each version of ruby you install will have its own gems. This is a good thing because native extensions likely won't work across ruby versions.)
You do have to be a bit more aware, because most commands, like rake, will load the newest version of rake that you have installed. You'll need to run bundle exec rake ... to make sure the correct version is loaded. Usually I'll run bundle exec for all commands except rails. You can create an alias to make it shorter (I use bex). To automate this with gem executables, you can use rbenv-binstubs, but you still have to be aware that running non-gem executables like ruby and irb won't automatically use the Gemfile.
Sidenote: rails new will run bundle install, which will check for the newest version of the dependencies. If you want bundler to try to use currently installed gems that satisfy the dependency requirements, you can skip the bundle install with rails new --skip-bundle, then run bundle check in the app dir.
Sidenote 2: suppose you want to use a ruby version for Project2 (e.g. 2.1.8) that's different from the default (e.g. 2.3.0). In that case, running gem install as specified above will install the gems under 2.3.0, which is a waste of time because you'll need to install the gems again under 2.1.8. To solve that problem, you can force the commands to use the preferred version via environment variable:
RBENV_VERSION=2.1.8 gem install rails -v 3.2.13
cd ~/projects
RBENV_VERSION=2.1.8 rails _3.2.13_ new Project2
echo 2.1.8 > Project2/.ruby-version
You could use rbenv shell to set the variable, but I only recommend that if you don't want rbenv to auto-switch based on .ruby-version files for the duration of that shell. It's very easy to forget that you have the variable set, and when you cd to a different project, it won't be using the version you expect.
There's a good recent post on exactly the topic of gemsets / bundler here http://rakeroutes.com/blog/how-to-use-bundler-instead-of-rvm-gemsets/ Good background you can apply to your rbenv setup.
I set up RVM and used it to install Ruby and a few other libraries. As I was going through various tutorials and set-ups of other technologies like Rails, I began getting confused about what I should do via RVM and what I should just do as the tutorials suggest.
One example is the RubyGems tutorial here:
http://rubygems.org/pages/download
Should I download that tar file they are talking about? Seems unnecessary since that is what I thought RVM was for. Do I even need RubyGems? What is that for really?
Also, how do I actually get Rails? Is there a precise RVM command to actually download and install Rails?
It helps me to think of RVM as a layer of abstraction between you and the ruby ecosystem.
Without RVM: ruby, gems, and ruby related binaries (like rake, spec, gem, etc) are all installed directly into your operating system directories.
With RVM: ruby related stuff is intercepted by rvm so that ruby, gems, and ruby related binares are "installed" into ~/.rvm dir in a nice, clean, organized way. RVM sits between ruby, gems, and related binaries and the operating system. It provides a way to have multiple ruby environments (with different gems and binaries) on the same machine.
So, no matter whether you have rvm installed or not, you should be able to run the commands almost exactly(*) as they appear in any tutorials out there on the web. In other words, you can sort of "forget" that RVM is installed; the ruby ecosystem should work just as if it wasn't installed.
So, yep, you're gonna have to run gem install rails, etc.
Hope that helps clear the confusion.
(*) There are some small differences. For example: you shouldn't run commands as sudo when RVM is installed.
Should I download that tar file they are talking about?
No. Ruby 1.9+ includes gems. RVM retrofits it for 1.8+.
In general, be careful with any directions you find on the internet explaining how to install anything, unless you have enough experience to understand completely what they want you to do. In particular, any time they want you to install something using sudo or as root.
Specifically, when working with RVM, you do NOT want to use sudo to install Ruby, or any gem. RVM works by setting up a sandbox for your development, and relies on your account's environment, modifying your path so any Ruby requests go to the currently selected RVM-managed Ruby or gems or any commands they install. sudo pushes your normal environment to the side, substituting root's temporarily, installs whatever you asked it to do with root's permissions, then reverts to your environment.
When you go to run the command, or find the gem, as you, it can't be found by RVM's Ruby, because the file was installed outside RVM's sandbox, or, it can't be read or modified, because it's owned by root. Whatever the actual cause, the end result will be weeping and gnashing of teeth.
RVM doesn't subvert the gem functionality. gem is used to install and manage Ruby gems, and RVM tweaks it to use the sandbox for all its machinations. You get added functionality because of RVM's support of gemsets, but gem works as it always has, only it has "big brother", RVM, controlling its world.
No need to install rubygems. RVM should have already installed rubygems. RVM is (in my opinion) useful for managing different installations of ruby (say 1.8.7 and 1.9.2) or different gemsets. If you just have one version of ruby and don't care about different gemsets, RVM isn't really that much of a change. If you want to just install rails, just use gem install rails. If you have an existing rails 3 app, install bundler first gem install bundler and then bundle install to get rails and other gem dependencies.
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 =)