Trouble understanding RVM, gems, and general Ruby on Rails environment setup

Question

I've read through a few Q&A's here on this subject, but am still confused. I'm new to linux and new to programming, so please keep that in mind.

I understand that Ruby Gems is similar to apt-get. It's a package manager -- correct?

So if I want to install or remove gems, I can do it via a command like: sudo gems install {gem name}

So what then is RVM? Why would I want to use it? Doesn't Ruby Gems do what RVM does? Why then does Ruby Gems get installed with RVM?

Also, when specifying gems in a project's Gemfile, then using bundler to update, etc.. is this downloading the gems only to that project, or will they now be available across all projects?

Also, what is $PATH about? I don't know much about it, so when I read about it, I'm confused about what is the right $PATH, what if anything I should do to manage references in $PATH, etc. Can someone explain or point to any resources for beginners?

And finally, I'm using various tutorials, and they differ on versions for everything from Ruby to Rails to Gems. a) Should I be modifying my environment to match the version that they use? b) Once I'm done with a tutorial, should I leave all the versions alone, or should I try to upgrade everything up to the latest and greatest?

It's confusing because if I leave everything at the version levels in the tutorials, then I feel like I'm stuck in the past. While if I upgrade to the latest and greatest, I feel like things have all switched around on me and I'm not sure how to use all the tips and tricks I learned.

Thank you in advance for taking the time to help. Cheers.

Answer 1

This question is very broad so I chose to try to balance the explicitness with conciseness. If anyone finds anything wrong with the answer please tell and I'll straight up own up to it :)

RVM is a Ruby Version Manager. Hypothetically, some projects might require you to run ruby 1.9, another legacy project might require 1.8. RVM allows you to have both installations installed side-by-side, as opposed to having one authoritative system-level version of ruby. This facilitates installing later versions of ruby without fear of breaking anything, or of meddling with other user accounts' ruby version requirements (since usually one installs RVM at the user level, in your home directory). This even lets you try out the bleeding edge version of ruby without having anything to worry about, since you can always switch back easily.

When you install a gem, it generally becomes available to you everywhere that ruby installation is available to you, so in any project. When you specify gems in your Gemfile you're basically saying that independently of whatever gems you may have installed and their versions, that project requires gem x of version 2.2, y of version 3.1, and z of version 1.1. If you didn't already have those gems it installs them, if you did but not those versions, it installs them.

Path is an environment variable that allows operating systems to know where to look for programs when you invoke them. If you type someapp in the terminal, how can the operating system possibly know where someapp is? Well it searches for it in any of those directories supplied in $PATH. You can see what's in your path by doing echo $PATH in the shell.

As for varying versions of ruby, this brings me back to the reason for RVM. You can if you want install the version of ruby they use, and then in your Gemfile specifically state the version of the gems the tutorials use and you should be fine. You can have different versions of gems installed, and you can have different versions of ruby installed thanks to RVM.

Personally I would recommend working towards the latest version of everything so that it remains relevant. For example, it would be counterproductive to work on a tutorial that uses Rails 2 since it changed a lot when it went to 3, and somewhat from 3 to 3.1 and above etc. If possible use the latest versions, or at least be aware of the nuances (the base material tends to stay more or less the same), lest you work on a tutorial that is older only to get to work on your own project with the latest version of everything and not have it work.

Simple solution to your dilemma: ditch the tutorials that are too old. There are tons of resources out there that you're bound to find up-to-date material. Worst case, dated material typically has community support in form of comments which state the changes between the dated version of something and its corresponding recent version. Eg "keep in mind that haha.what changed to lol.wut in version 3.1"

Answer 2

I can understand that this is confusing, RubyGems are as you write a package manager. RVM is a tool that makes it possible to have several versions of ruby installed on your system and easy swift between them.

If you using various tutorials, and they differ on versions for everything from Ruby to Rails to Gems you can (if you want to) create a RVM Gemset for the version you use. You will then create a sandbox for the Gems Bundler use in your project.

Bundler are as you write a tool for manage the Gems your application depends on. In the old days before Bundler it could be a hassle to figure out which gems your application depended on. Now Bundler do this for you.

Both Bundler and RVM are tools that is not absolutly necessary to use but they will help you. I personally do not use RVM anymore. It is to much of a monster in my taste so I use rbenv instead.

Regarding what versions of Rails to use I do agree that you should try to use 3.1 versions if possible but if you find some example application using Rails 3.0 you do not need to upgrade it. Also you do not need to run the absolute latest version of Rails. Rails 3.1 have a lot of bug fixes that the latest Rails 3.1.3 might not have.