I have several servers for development, staging, testing and production and want to keep my Ruby version and Gem versions in sync between the different machines -- what's the best way to do this?
If you're using Rails 3, you can just use the Gemfile, and bundler, and when you do a "bundle update" on whatever machine you're on, it will automatically install the correct versions of Gems for that user account.
You should use RVM to manage your Ruby versions and to keep the Gems for different Ruby versions separate from each other.
You should also create a "gemset" for your Rails application, to make sure that the Gems installed there are not modified from another Rails application you might use or develop on the same machine.
http://beginrescueend.com/
http://railscasts.com/episodes/200-rails-3-beta-and-rvm
rvm is the best option to manage ruby versions
However I am not sure if you really want to change ruby version often.
bundler & Gemfile is great way to handle gem versions
Track you Gemfile && Gemfile.lock files in git(or other cvs) tree, and run bundle install on change
You can also, in the event you have more gems in a gemset than just what's in your Gemfile, do a
rvm gemset export gemsetname.gems
And then on the other machine you would do a
rvm gemset import gemsetname.gems
You can even do it as
rvm x.x.x#mygemset exec rvm gemset export mygemset.gems
so you don't have to go directly into your gemset. And then on the new machine,
rvm --create use x.x.x#mygemset && rvm gemset import mygemset.gems
which will create and then populate your mygemset gem set.
Related
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'm having difficulty understanding RVM per project gemsets. I've installed RVM and the 1.9.2 and 1.8.7 rubies, as per http://beginrescueend.com/interpreters/ruby/ , and when I want to start a new project, I've been
cd ~/Code
rvm use 1.9.2
rvm gemset create test1
rvm gemset use test1
gem install rails
But this takes a long time! (installing rails). I then rails new test1; cd test1
I'm really unsure with the correct workflow. If I'm making a new app to test in, I don't want to have to wait for rails to install.
It seems from http://beginrescueend.com/gemsets/basics/ that I can create a rails gemset, but then how do I create a per project gemset?
Edit:
If I'm going to using multiple ruby/rails versions, should I create a gemset, say 1.9.2#rails313, then rails new blah, put 1.9.2#rails313 in blah/.rvmrc , and if I need to later on, create a blah gemset?
A gemset is just a container you can use to keep gems separate from each other.
The Big Idea: creating a gemset per project allows you to change gems (and gem versions) for one project without breaking all your other projects. Each project need only worry about its own gems. This is a Good Idea, and the wait time for installing large gems like Rails is usually worth it.
That said, if you're going to use the same version of Rails across all your projects and want to save time, you can install rails (and maybe rake as well) in the 'global' gemset - these gems are available in all gemsets for that version of ruby.
Assuming you already have a test1 gemset:
$ rvm gemset use global
$ gem install rails
$ gem install rake
$ rvm gemset use test1
$ rails test1
Once I wrote a simple blog post on how to use RVM with gem sets, this might be helpful to you.
UPDATE: As the link above is dead, I believe it is in another location here.
I am exploring the world of Ruby and RVM. I am going through a lot of documentation and trying out RVM, but I am a bit confused about the entire work flow. I am writing down the workflow as I understand it. Can someone please take a look and see if this understanding is correct?
I am using a Mac.
RVM is essentially a script that allows us to manage Ruby environments for development purposes.
RVM allows switching between different versions of Ruby with rvm use 1.9.2.
To use a particular gemset with the current Ruby version, we need to create a gemset using
rvm --create gemset rails235
Install the gem using gem install rails -v=2.3.5
Q: What happens if I did gem install rails -v=2.3.5 prior to creating a gemset? Will there be two copies of the same Rails installed under RVM's Ruby 1.9.2?
Q: What happens if I install 2.3.5 and 3.1.0 prior to creating gemsets and then create a gemset for each version?
Q: where does rvmrc come into picture in the whole story?
Any other information that helps me get this straight is extremely helpful.
#Kiran, this is in reference to your comment above. When you install a different version of ruby with rvm, it'll add to this list:
$ rvm list
rvm rubies
=> ruby-1.9.2-p290 [ i386 ]
On my system, I've only got one version running (for now). This helps too
$ rvm gemset list
gemsets for ruby-1.9.2-p290 (found in /Users/mike/.rvm/gems/ruby-1.9.2-p290)
global
=> mg_diaspora
rails3
railscasts
ruby
sorcery
The practice is to install common gems into your global gemset and create/use sets for everything else. I tend to keep pry and others in the global gemset. As Mike K. said, you'd never do #2; if you did do such a thing, I would imagine global having priority.
#3 .rvmrc
You can do things like this in the file:
rvm use 1.9.2#rails3 --create
This will ensure whenever you 'cd' into the directory, it'll switch to 1.9.2 and it's 'rails3' gemset; the following attribute ensures the gemset will be created if it doesn't already exist.
Update
Ex: if I say rvm use 1.9.2#rails3 --create how does this pick the version of rails3.1.0 gem
Because by the time this rails3 gemset is created I already have 2 versions of rails gems?
That's easy - when you run bundle install it creates a Gemfile.lock; this essentially 'locks' the gems that your application is set to use. You've never require two different versions of rails in a single Gemfile anyways - that's just ridiculous =)
1) Rvm automatically creates an #global gemset per interpeter so if you did what you state in the first question you'd have a 2.3.5 in the global gemset.
2) I'm not sure why you would do this.
3) rvmrc is just where you can specify environment info like bashrc, i use it to specify my default architecture for instance. It gets read when rvm gets sourced in your profile.
Basically global is a mix-in for all other gemsets under a specific interpreter. So, if you put rake and say bundler into the global gemset, and then create and enable your own gemset under that specific ruby, it will have both the gems you install in that gemset AND global.
You will see it as a single gemset though. Also, if you attempt to delete a gem that is in global while still in, say, mygemset you will not be able to delete it. This is to protect other gemsets from having gems mixed in from global that they rely on from being removed. You would have to either explicitly change to global or execute something like
rvm 1.9.2-p290#global exec gem uninstall rake -v='0.9.2'
Also, bear in mind that there is a significant difference between 'default' and 'global'. The 'default' gemset is not really a gemset perse. This is selected when you do something like
rvm use 1.9.2
Notice you did not select a gemset in the above command. This is where default lives and plays. When no gemset is selected, default becomes active and global totally disappears. To load default, you would modify $rvm_path/gemsets/default.gems as these are the list of gems to be installed into each interpreter's 'default' set. The other file there is 'global.gems'. This is used as you would surmise; to load a default set of gems whenever you install a new interpreter under RVM into the global gemset, which is shared by all other gemsets for that Ruby, but not for 'default'.
Please see https://rvm.beginrescueend.com/gemsets/basics/ for more information.
What are the benefits & drawbacks of installing things into the #global gemset in RVM?
Let's say I want to install different versions of rails on the same server. I then want the ability to install multiple ruby apps on the same server, with the least duplication of files to save on disk space. However, I still want to avoid dependency problems, gem conflict issues and other problems.
Let's also assume that each app has extra gems it needs that I only want in it's local project gemset.
Would I be better off:
Installing both Rails 3 and Rails 2 gems into the #global gemset
...And use project-local gemsets for their gems...
Installing Rails 3 into a #rails3 gemset, and Rails 2 into a #rails2 set... then cloning for each project I need?
For example:
rvm use ree#rails3 && rvm gemset export rails3.gems
rvm use ree#rails2 && rvm gemset export rails2.gems
rvm use --create ree#project1-on-rails3 && rvm gemset import rails3.gems
Install more project-local gems here...
rvm use --create ree#project2-on-rails2 && rvm gemset import rails2.gems
Install more project-local gems here...
Something else entirely...
NOTE: I wrote this whole response assuming that you are using Bundler to manage your gem dependencies. I realize that some people don't, and you didn't mention Bundler in your question. If you aren't using Bundler, I would point out that it probably is the best way to conserve disk space (only if you bundle install --system, though!). If you are using exported gemsets to manage dependencies, I think your scheme sounds reasonable, but I have no experience with it.
Both Rails 3, and Rails 2 with Bundler will set their load path appropriately such that they will not load any gems (or any versions of any gems) that are not in the Gemfile.lock. There's not really any way that I've experienced to have a "gem dependency problem" on the server. It is important that you run bundle install on your development machine whenever you modify the Gemfile, and that you check your Gemfile.lock into source control, as described on the Bundler homepage.
I spent some time digging into the use-cases of gemsets back in January. The reasons I found to use separate gemsets for each project were:
Your shell environment is the same as your application environment (scripts run correctly without bundle exec).
You can easily browse and grep through the source code of all your dependencies, by navigating to the gemset install directory.
It prevents some reported ‘heisenbugs’, according to the author of RVM. I have experienced something like this where a gem executable wasn't available and bundle exec didn't seem to help.
I don't think any of these benefits are very compelling on the server, so if you are aiming to conserve disk space, I'm not sure why you would use gemsets at all.
Actually, the only reason I've used rvm at all on the server was because it was a convenient way to build ruby from source (we needed a version that wasn't available in the native package manager).
Is there a way to install a Rails 2.3.10 app if I have Rails 3.0.3 installed on my machine?
for example i'd like to start my server with ruby script/server instead of rails server.
thx
Two main ways:
Bundler: you can create a Gemfile and use bundler to silo the gems for each of your installations. The drawback to this one is that you'll probably have to use "bundle exec command" whenever you want to run a command for the version of rails you're using, such as spec or cucumber
RVM: using RVM you can use not only different versions of Ruby, but also separate gemsets within a version of Ruby. I personally use this method most of the time, creating a gemset called "rails3" and "rails2" (or sometimes I use a gemset for the application) with the relevant gem versions in it. You can have as many gemsets as you want and switch between them. Stick a .rvmrc file in the root of your application, and rvm will switch the version of ruby and your gemset for you automatically.