rbenv: Surviving without gemsets

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 myappcd myappecho "source :rubygems" > Gemfileecho "gem 'rails', '3.2.2'" >> Gemfilebundle install --path vendor/bundlebundle 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.13cd ~/projectsrails _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.13cd ~/projectsRBENV_VERSION=2.1.8  rails _3.2.13_ new Project2echo 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.