THE RUBY WAY, Third Edition (2015)
Chapter 21. Ruby Development Tools
Man is a tool-making animal.
—Benjamin Franklin
A development environment consists of more than just an interpreter. Every good developer is surrounded by a selection of tools that make life easier. Some of these may be language specific, and others may not.
The most important of these is the editor. Because much of what programmers do day-to-day is manipulate text, the choice of editor (or your proficiency with it) has a significant impact on productivity. The language-specific features or the customization capabilities also have an impact. We’ll look very briefly at the most common editors here.
Other tools may assist in documentation, library installation, debugging, and similar tasks. We’ve already looked at the Byebug debugging library (which is not a real standalone application) in Chapter 16, “Testing and Debugging,” and we’ve looked at Rubygems, Bundler, and RDoc inChapter 17, “Packaging and Distributing Code.” These are not covered further here.
This chapter starts off with rake, the Ruby version of the UNIX make tool. It also covers irb and pry, both interactive Ruby shells, and ri (the command-line documentation tool). Finally, we wrap up with discussion of Ruby version managers.
21.1 Using Rake
The rake utility is like a Rubyesque version of the UNIX make utility. Instead of the complex and difficult Makefile syntax (which you may know and hate), it uses only pure Ruby code. This utility is the work of Jim Weirich and may be the first formal instance of a DSL (domain-specific language) in Ruby.
You may see the name spelled “Rake” or “rake.” The former is the name of the tool, and the latter is the actual name of the executable itself. It’s not worth nitpicking, in my opinion.
Rake (which is definitely inspired by make) allows you to define tasks, declare dependencies between tasks, and then run a task and all of its dependencies at once. The terminology used is much the same as that of make. We still talk about targets, actions, dependencies, and rules.
The uses of Rake are numerous. If you are working with C, C++, or Java code, you can use it to build your projects. (It will work for other languages, too, of course.) You can also use it for generating documentation with RDoc, deploying software, updating a RubyForge project, and many other such tasks.
Like make and the Makefile, Rake operates on a file of instructions called the Rakefile. If you want to give the file a different name, you can tell Rake that name using the -f or —rakefile option:
$ rake # look for 'Rakefile'
$ rake -f myfile # use 'myfile' instead
The basic “unit of work” in Rake is the task; these are named with Ruby symbols. Every Rakefile is understood to have a default task called :default, which will be run if you don’t specify a task name:
$ rake # execute the default task
$ rake mytask # execute 'mytask'
Inside a Rakefile, we declare and create a task using the task method, passing it a symbol and a block:
task :mytask do
# ...
end
The “stuff” that goes inside the block, which we refer to as an action, will be run whenever the task is run by name. An action can be anything and can involve arbitrary Ruby code. Some convenience methods are available for common operations. The sh method (meant to remind us of the UNIX sh executable) will run a system command. The methods cp, mv, and rm are respectively for copying, moving, and deleting files. (Like the make utility itself, Rake has an unabashed UNIX flavor about it.) For a complete list of Rake’s helper commands, consult the Rake API documentation at rdoc.info or ruby-doc.org.
If you prefer to use braces to delimit a block, you can, but the Ruby parser will typically force you to use parentheses around the parameter in that case:
task(:mytask) { do_something }
Now, let’s take a more concrete example. Imagine we have a C program named myprog.c with two other C files associated with it (each with its own header file). In other words, we have these five source files:
myprog.c
sub1.c
sub1.h
sub2.c
sub2.h
We want to compile all this together into the executable myprog. This is a multistep process: First, we will compile all the .c files; then we will link the resulting .o files together.
Rake provides a shortcut for declaring that a file can only be created if another file already exists. Let’s begin by using that shortcut, the file method, to specify file dependencies:
file "myprog.o" => ["myprog.c"]
file "sub1.o" => ["sub1.c", "sub1.h"]
file "sub2.o" => ["sub2.c", "sub2.h"]
file "myprog" => ["sub1.o", "sub2.o"]
Notice how the file method just takes a hash. It associates a filename with an array of dependent filenames.
Now let’s look at building the binary files. We’ll take the code we just wrote and extend it a little. If we put a block on the file call, we can declare the actions that will produce that file:
file "myprog.o" => ["myprog.c"] do
sh "cc -c -o myprog.o myprog.c"
end
file "sub1.o" => ["sub1.c", "sub1.h"] do
sh "cc -c -o sub1.o sub1.c"
end
file "sub2.o" => ["sub2.c", "sub2.h"] do
sh "cc -c -o sub2.o sub2.c"
end
file "myprog" => ["sub1.o", "sub2.o"] do
sh "cc -o myprog myprog.o sub1.o sub2.o"
end
There is some duplication here, but we can get rid of it. As it turns out, Rake has a special facility called a FileList; it understands wildcards (glob patterns) and allows us to work with multiple files at once. Here, we find all the .c files. This FileList acts much like an array:
FileList["*.c"]
Therefore, we could use each to set our file actions; we do so in the following code fragment. (And note that the dependencies are not specified here; Rake is smart enough to combine the dependencies and actions internally if we specify the dependencies elsewhere.)
FileList["*.c"].each do |src|
obj = src.sub(/.c$/,".o")
file(obj) { sh "cc -c -o #{obj} #{src}" }
end
However, it’s simpler to use rules, which are another Rake feature (naturally lifted from make):
rule '.o' => '.c' do |target|
sh "cc -c -o #{target.name} #{target.source}"
end
A small bit of magic happens here. The source attribute gets set internally, and automatically replaces the file extension from the hash key with the extension from the hash value (changing .o to .c, in this case).
Now let’s do a little more magic. If we require the rake/clean library, the constants CLEAN and CLOBBER (initially empty) and tasks :clean and :clobber are defined for us. These are traditionally named targets; clean will remove any temporary files, and clobber will remove all these and the final results as well.
These array-like constants have an include method that takes a file glob. This is like an implicit use of FileList.
Therefore, our Rakefile now looks like this:
require 'rake/clean'
CLEAN.include("*.o")
CLOBBER.include("myprog")
SRC = FileList['*.c']
OBJ = SRC.ext('o')
rule '.o' => '.c' do |t|
sh "cc -c -o #{t.name} #{t.source}"
end
file "hello" => OBJ do
sh "cc -o hello #{OBJ}"
end
file "myprog.o" => ["myprog.c"]
file "sub1.o" => ["sub1.c", "sub1.h"]
file "sub2.o" => ["sub2.c", "sub2.h"]
task :default => ["myprog"]
Notice how we don’t have to specify “clean” and “clobber” tasks explicitly. Also note that a “clobber” implicitly includes a “clean” operation. Finally, note that we specified a default task for the convenience of the person running the Rakefile; it’s now unnecessary to specify a task in order to compile.
Rake has several useful command-line options. Sometimes you want to test a Rakefile without actually doing any (potentially dangerous) operations; the -n and --dry-run options will allow this. The -T option will list all the targets in a Rakefile. There are also options controlling library path searching, tracing and logging, and more.
Rake is more complex than I’ve hinted at here (especially the rules). The popular deployment tool Capistrano is based on Rake. In addition, most Rubygems use Rake to some extent to help automate repetitive tasks. Read the Rake documentation (available at rdoc.info or ruby-doc.org) for more details, and search online for posts and tutorials about how to accomplish specific tasks you are interested in.
21.2 Using irb
The irb utility (interactive Ruby) has been distributed with Ruby for many years. It can be thought of as a “testbed” or “playground” where you try out quick hacks and new ideas.
Basic usage of irb is simple. When you start it, you get a prompt where you can type Ruby expressions; each expression is evaluated, and the result is printed for you. Here’s a small example of a session:
$ irb
irb(main):001:0> "cell" + "o"
=> "cello"
irb(main):002:0> 3*79
=> 237
irb(main):003:0> Dir.entries(".").size
=> 17
irb(main):004:0> rand
=> 0.850757389880155
irb(main):005:0> rand
=> 0.679879756672551
irb(main):006:0> defined? foo
=> nil
irb(main):007:0> defined? Object
=> "constant"
irb(main):008:0> quit
$
Of course, it’s more than just a calculator. You can type in arbitrary Ruby code if you want:
[hal@localhost ch21]$ irb
irb(main):001:0> require 'mathn'
=> true
irb(main):002:0> gen = Prime.instance
=> #<Prime:0x000001019e62e8>
The -r option will do a require so that you can include code from a file. Suppose we have the following source file:
# File: foo.rb
class MyClass
attr_accessor :alpha, :beta
def initialize(a, b)
@alpha, @beta = a, b
end
end
obj1 = MyClass.new(23,34)
obj2 = MyClass.new("abc","xyz")
Then we can do this:
$ irb -rfoo
irb(main):001:0> obj = MyClass.new(88,99)
=> #<MyClass:0x00000102830c90 @a=88, @b=89>
But notice that although we can get at the contents of the file (for example, the constant MyClass), that doesn’t include the local variables. The local variables for a file are accessible only within that file; a require (inside or outside irb) won’t allow you to see them.
Newbies are sometimes confused by output printed in irb:
$ irb -rfoo
irb(main):001:0> puts "hello"
hello
=> nil
What is the nil doing there? It is the return value from the puts method, dutifully printed out by irb once the method has run.
Be aware that irb is highly customizable. When you start it up, it reads whatever initialization data it finds first, looking for an existing file from this list, in order:
• ~/.irbrc
• .irbrc
• irb.rc
• _irbrc
The initialization file is pure Ruby. It enables customization of prompts and much more. For a complete discussion of this file, the best source is Programming Ruby by Dave Thomas and Andy Hunt (also called “the pickaxe book” after the cover illustration). This section will only mention a few highlights.
If your Ruby installation is built with GNU readline support (as is usually the case), you can use the up and down arrow keys to navigate back and forth in the command history. More importantly, you can get Ruby tab completion. This works in a predictable way: When you type a partial identifier and then press the Tab key, irb tries to complete the rest of the identifier name for you.
To enable tab completion, add this fragment to your .irbrc file:
IRB.conf[:AUTO_INDENT] = true
IRB.conf[:USE_READLINE] = true
IRB.conf[:LOAD_MODULES] ||= []
IRB.conf[:LOAD_MODULES] |= ['irb/completion']
Bear in mind it’s possible to put arbitrary code in your .irbrc file. For example, here is a method I find useful sometimes. It is named sm for brevity (“show methods”); its purpose is to list (in alphabetical order) all the methods that can be called on an object, excluding the ones it gets from its ancestors:
def sm(obj)
list = obj.methods
anc = obj.class.ancestors - [obj.class]
anc.each {|a| list -= a.instance_methods }
list.sort
end
The following is an example of its usage:
irb(main):001:0> str = "hello"
=> "hello"
irb(main):002:0> sm str
=> [:%, :*, :+, :<<, :[], :[]=, :ascii_only?, :b, :bytes,
:bytesize, :byteslice, :capitalize, :capitalize!, :casecmp,
:center, :chars, :chomp, :chomp!, :chop, :chop!, :chr, :clear,
:codepoints, :concat, :count, :crypt, :delete, :delete!,
:downcase, :downcase!, :dump, :each_byte, :each_char,
:each_codepoint, :each_line, :empty?, :encode, :encode!,
:encoding, :end_with?, :force_encoding, :getbyte, :gsub,
:gsub!, :hex, :include?, :index, :insert, :intern, :length,
:lines, :ljust, :lstrip, :lstrip!, :match, :next, :next!, :oct,
:ord, :partition, :prepend, :replace, :reverse, :reverse!,
:rindex, :rjust, :rpartition, :rstrip, :rstrip!, :scan, :scrub,
:scrub!, :setbyte, :size, :slice, :slice!, :split, :squeeze,
:squeeze!, :start_with?, :strip, :strip!, :sub, :sub!, :succ,
:succ!, :sum, :swapcase, :swapcase!, :to_c, :to_f, :to_i,
:to_r, :to_str, :to_sym, :tr, :tr!, :tr_s, :tr_s!, :unpack,
:upcase, :upcase!, :upto, :valid_encoding?]
irb(main):003:0> sm String
=> [:allocate, :new, :superclass, :try_convert]
irb(main):004:0> sm 123
=> [:&, :*, :**, :+, :-, :/, :<<, :>>, :[], :^, :bit_length, :size,
:to_f, :|, :~]
It’s not seen much, but irb makes it possible to run subsessions within a session. It’s possible to run multiple sessions and switch back and forth between them; each one maintains a separate binding.
That may not necessarily seem useful, but one trick that makes it more useful is to specify an object along with the irb subcommand. Then the context of the subsession is that object; self is set as you would expect, the scope is that of the object, and so on:
$ irb
irb(main):001:0> t0 = Time.now
=> 2014-08-29 19:01:42 -0700
irb(main):002:0> irb t0
irb#1(2014-08-29 19:01:42 -0700):001:0> strftime("%a %b %c")
=> "Fri Aug Fri Aug 29 19:01:42 2014"
irb#1(2014-08-29 19:01:42 -0700):002:0> to_i
=> 1409364102
irb#1(2014-08-29 19:01:42 -0700):003:0> self + 1000
=> 2014-08-29 19:18:22 -0700
irb#1(2014-08-29 19:01:42 -0700):004:0> wday
=> 5
irb#1(2014-08-29 19:01:42 -0700):005:0> class
SyntaxError: (irb#1):5: syntax error, unexpected end-of-input
irb#1(2014-08-29 19:01:42 -0700):006:0> self.class
=> Time
irb#1(2014-08-29 19:01:42 -0700):007:0> quit
=> #<IRB::Irb: @context=#<IRB::Context:0x007ff9430437d0>,
@signal_status=:IN_EVAL, @scanner=#<RubyLex:0x007ff94303b238>>
irb(main):003:0> quit
$
Another library that can be helpful for examining the results of Ruby code is the xmpfilter, which is part of the rcodetools gem. It takes Ruby statements, evaluates them, and places the return value in comments.
There is another “goodie” associated with irb that you might like to know about. Naturally irb is capable of analyzing Ruby code; the lexer is easily used by other applications as well. Here is a simple example of a program that opens its own file to analyze itself; it produces a sorted list of all identifiers and constants used in the program:
require 'irb/ruby-lex'
file = File.new(__FILE__)
parse = RubyLex.new # (file)
parse.set_input(file)
idents = []
loop do
token = parse.token
break if token.nil?
if token.is_a? RubyToken::TkIDENTIFIER or
token.is_a? RubyToken::TkCONSTANT
idents << token.name
end
end
p idents.uniq.sort
# Output:
# ["File", "RubyLex", "RubyToken", "TkCONSTANT", "TkIDENTIFIER",
# "file", "idents", "loop", "name", "new", "p", "parse",
# "require", "set_input", "sort", "token", "uniq"]
So far as I am aware, this is not documented anywhere in English. But if you need a Ruby lexer, you can probably read the source and adapt this one for your needs.
21.3 The Basics of pry
The pry tool is not a standard part of Ruby, but it has gained great popularity. You can think of it as an “enhanced irb” if you like.
Its use as a debugging tool is covered in Chapter 16. Here, we’ll look a little further, at ways that pry can assist with interactive development.
Because pry is a complex and powerful tool, we can only scratch the surface here. As always, consult the documentation for additional detail.
Keyboard input in pry is fairly flexible. You can, of course, use the cursor keys to scroll through the command history, but there are also various commands that allow you to view and edit the input buffer in ways that irb does not support.
Some of the relevant commands are shown here:
show-input Display the entire input buffer
amend-line n newtext Replace line n with newtext
! Break out of read loop and empty input buffer
hist —tail k Show line k of the history
hist —replay m..n Replay lines m through n of the history
edit Open the input buffer in an external editor
The edit command can also be used to edit a class, method, or even just the file containing the code that is currently executing (with edit -c). When the editor is closed, pry will reload the edited file, overwriting existing class and method definitions with new ones from the file.
As in irb, you can use an underscore (_) to retrieve the value of the last expression evaluated. To evaluate an expression without displaying this value, you can end an expression with an ampersand; this is useful, for example, when you evaluate an expression with a very lengthy result. Finally, the input and output are stored, respectively, in “variables” called _in_ and _out_:
_ Value of last expression evaluated
expr; Evaluate expr, but do not print its value
_in_ Console input
_out_ Console output
To send a command to the operating system, you can preface it with a dot. You can also interpolate Ruby code as needed:
.ps aux Run the command "ps aux"
.ps aux | grep #{prog} Run ps aux and grep for (the value of) prog
There is also a shell-mode feature. This basically adds the current directory to the pry prompt and enables (some) filename completion.
The show-source command is for viewing source code, including the source of pry itself, of C extensions, and so on. There are options to modify its behavior.
The show-doc command displays documentation. It can give information on classes, methods, parts of the Ruby core, and so on. Related commands are stat and ri (which invokes the ri tool, examined in the next section).
Finally, the help command displays information on pry features and usage. Other than online references and tutorials, this is your best source of knowledge for this powerful tool.
21.4 The ri Utility
The ri tool is named from “Ruby index” or some such mnemonic. It is a command-line documentation tool, offering information on Ruby classes, methods, modules, and so on. Here is an example:
(from ruby core)
Implementation from Enumerator
e.with_index(offset = 0) {|(*args), idx| ... }
e.with_index(offset = 0)
Iterates the given block for each element with an index, which
starts from offset. If no block is given, returns a new Enumerator
that includes the index, starting from offset
offset
the starting index to use
By default, installing gems with Rubygems will also generate ri format documentation, making it available via the ri command.
21.5 Editor Support
Any modern editor should be programmer friendly. With memories of the twentieth century growing dim, we take it for granted that our editors will reconfigure themselves based on the kind of file we are editing. We expect syntax highlighting, auto-indent, and other such features as a matter of course.
The Ruby coder will not be disappointed by the tools and features out there. Many of these are now standard with an editor’s distribution; others are not. Let’s take a quick look at what’s available.
Two excellent graphical text editors are SublimeText 3 ($30, available for Windows, Mac OS X, and Linux), and TextMate 2 (free, Mac OS X only). Both have good Ruby support and can be extended with additional commands and text snippets to increase coding efficiency. TextMate’s popularity has decreased in recent years, largely due to several years without a release between version 1 and 2, but is still quite popular. SublimeText has a significant following and continues to gain in popularity.
A third is RubyMine, which is based on Java’s Eclipse IDE. Developers coming from Ruby to Java may find it more familiar than other options. This is not just an editor but an IDE in itself—arguably the best (and last surviving) of the IDEs. It is a commercial product, but it is worth having if you want powerful editing features as well as integration with tools and documentation.
Although graphical editors have gained popularity in recent decades, the most common editors in the programmers’ world are still Vim and Emacs. Let’s look at these briefly.
21.5.1 Vim
Vim users are provided Ruby features by the plug-in named vim-ruby. This set of config files offers syntax highlighting, auto-indent, and code completion. It also enables such things as invoking the Ruby interpreter from within the editor (compiler plug-ins).
vim-ruby is included in most Vim distributions starting with version 7. However, you may find that these features are disabled (probably for backward compatibility). Turn them on by adding the following to your .vimrc file:
set nocompatible
syntax on
filetype on
filetype indent on
filetype plugin on
In addition, several excellent Vim plug-ins written by Tim Pope are probably worth installing. They can be found on his GitHub profile at https://github.com/ tpope:
• pathogen—A Vim plug-in manager.
• unimpaired—Handy bracket mappings.
• surround—Used to manage parentheses, quotes, XML tags, and more.
• fugitive—Git integration for Vim.
• rails—Better Rails file navigation and syntax highlighting.
• dispatch—A build and test dispatcher.
If you are using Vim to edit Ruby code, I recommend familiarizing yourself with these and other Ruby plug-ins.
Arguably there are many reasons to dislike Vim; one of the greatest reasons is surely vimscript. The good news is it’s possible to script Vim’s behavior using Ruby. The bad news is this is not well documented. If you want to learn about this, I recommend using :help ruby in Vim as a starting point. You can also look at VimRubyInterface for more information. Finally, do a search of http://vim.org to see what recent information you can find.
21.5.2 Emacs
The other most popular editor in the world is Emacs. Actually, to call it an editor is a bit misleading; it is more like a miniature operating system that happens to do text editing on the side. One of the great advantages of Emacs is that it is highly extensible; the user can program its behavior in a Lisp variant called elisp. The elisp language is more powerful than vimscript; however, it is just as difficult to read (but in a different way).
Emacs has shipped with built-in Ruby support, in the form of Ruby Mode, since version 23. Newer versions of Ruby Mode are included with Ruby itself. I am not an Emacs user—though I have great respect for those who are—and therefore cannot comment further. For more, see the Emacs Wiki or search the Web for “emacs ruby.”
21.6 Ruby Version Managers
In recent years, more tools have been developed to help us install Ruby versions and switch between them. Gem management also falls into this realm because gem versions may change as Ruby versions do (and even more often).
The Ruby Version Manager (rvm) has been a valuable tool in our toolbox since 2010 or earlier. This tool, along with Bundler, has been my habitual choice. But we’ll also look briefly at rbenv and chruby as well.
21.6.1 Using rvm
The first version manager is simply named Ruby Version Manager, or RVM. It provides tools to install multiple versions of Ruby, switch between versions, and change the default Ruby version for a machine or just a single project. You can learn more how to install and use it at http://rvm.io.
The first thing to understand about rvm is that it does not interact with the “system Ruby installation” at all. It only manages versions that it installs itself.
Here are some common commands:
rvm install ruby-2.0.0 Install/compile Ruby 2.0.0 and manage it
rvm uninstall ruby-1.9.2 Uninstall the 1.9.2 version
rvm use ruby-1.9.4 Switch the "current" Ruby to 1.9.4
rvm use system Switch to the (non-managed) system Ruby
rvm list Show a list of all Ruby installations
rvm current Show current Ruby environment information
Note that rvm has the concept of a gemset, which is a grouping of related gems relevant to the current project or environment. Much of this functionality is arguably handled as well or better by Bundler, which is described later in this chapter.
The “usual” Ruby (MRI, “Matz’s Ruby Interpreter”) is the default. Other Ruby interpreters are supported, including JRuby, Rubinius, REE, and MacRuby. For more information, visit the RVM website (http://rvm.io).
RVM’s approach is all-encompassing, and it makes changes to the way your shell, Rubygems, and Bundler work. Many argue it is overly complex, error prone, and intrusive in the OS environment. Simpler alternatives have been created. The most popular of those alternatives are rbenvand chruby. We’ll take a look at them now.
21.6.2 Using rbenv
The rbenv tool provides support for using multiple Ruby versions. Its philosophy is “Do one thing, do it simply, do it well.” Therefore, it does not handle Ruby installation, has no gemset management features, and is not particularly shell sensitive.
Those who use rbenv often use ruby-build for installation. Likewise, they may use bundler for gem management. These tools work essentially independently of each other.
rbenv determines which Ruby interpreter to use by checking these three sources: the RBENV_VERSION environment variable, a local .ruby-version file, and the global ~/.rbenv/version file. The .ruby-version file may be in a directory relative to the application itself or relative to the current directory.
If you have ruby-build on your system, then rbenv install will invoke it in order to install a Ruby version. These are separate packages that work together.
Here are some other rbenv commands:
rbenv versions List all Ruby versions
rbenv local ruby-2.0.0 Set the Ruby version for this directory
rbenv global ruby-1.8.7 Set the global Ruby version
rbenv shell jruby-1.7.1 Set the shell-specific Ruby version
rbenv rehash Run after installing gems or rubies
to enable their commands
rbenv which rake Display the full path to a command
rbenv whence rackup List all rubies having the given command
Note that the shell-specific version overrides the directory-specific local version, and both of these override the global version. When the global or local version is set, rbenv writes the version to a local or global dot file. When a shell-specific version is set, rbenv sets an environment variable.
The rehash command serves to “refresh” the shell’s knowledge of installed Ruby versions and installed gems. Use it any time you install a new version of Ruby or a new Rubygem via gem install.
Note that rbenv is incompatible with rvm. If you have rvm installed, you will have to uninstall it before using rbenv.
21.6.3 Using chruby
The most minimal of all the version management tools is chruby. At the time of this writing, the “guts” of the tool comprise fewer than 100 lines of bash code. It can install Ruby versions using either the ruby-install tool (by the same author) or the ruby-build tool (by the author of rbenv).
Chruby may be installed directly from GitHub, or via a tool such as homebrew or rpm. Refer to the chruby repository on GitHub for detailed setup instructions.
Its general behavior is mostly simple and strives to be intuitive. It sets environment variables including PATH, GEM_HOME, GEM_PATH, and RUBY_ROOT. It defaults to the system Ruby, and it supports fuzzy matching of version names. It can optionally support automatic switching of the active Ruby version via the .ruby-version files that are also respected by rvm and rbenv.
The chruby tool does not overwrite the cd command with a shell function (as rvm does), and it does not replace the ruby command and all gem commands with shell script shims (as rbenv does). It also doesn’t require write access to your Ruby installation in order to install gems, and it doesn’t require that Ruby versions be installed into your home directory.
Chruby usage is as follows:
chruby List all installed Ruby versions
chruby 2.1.0 Switch to Ruby 2.1.0
chruby system Switch to the system Ruby
chruby understands both bash and zsh. It permits migration from rvm or rbenv via the RUBIES variable. It also offers some support for interaction with tools such as capistrano, chef, puppet, and others.
For more information, refer to the chruby documentation online. The chruby repository on GitHub (github.com/postmodern/chruby) contains a readme and wiki that serve as a good starting point.
21.7 Conclusion
We’ve seen several tools in this chapter that make life easier for the Ruby developer. Common tools are irb, rvm, and others. We’ve also looked at editor and IDE support for Ruby.
However, the most important tool of all is not a piece of software. It is “peopleware”—the Ruby community itself. I urge you to seek out groups both online and offline, whether on the Web via Google and Stack Overflow, on IRC (especially on Freenode), or at a Ruby conference (whether international or local). We’ll all be there to help you.