Is Rvm Production Ready

Is RVM production ready?

I built RVM for production and added the developer 'niceties' later on.
If you would like more information read the documentation on the website and come talk to me in #rvm on irc.freenode.net sometime during the day EDT most days.

RVM vs native installation of ruby

Use RVM. Because it is more simple.

You'll have all distributions in one place, all gems in one place, and you're using the same tool that you use in development. There are no performance issues either.

Why can't I perform a multi-user RVM install in Ubuntu 11.04?

In my opinion, RVM on a production host isn't as useful as it is for a developer's sandbox. I think RVM is a great tool but it isn't for every situation.

Developers need a lot of flexibility for using different versions of Ruby, and for using specific versions of gems. RVM shines for that. It makes it easy to switch automatically, to test against all versions of Ruby installed, or, if things go haywire, to blow it all away and start over quickly.

In a production server environment, where you generally dedicate a host to a particular service, or a set of related services, the need to quickly switch between various Rubies and gem sets tends to disappear. I put only one version of Ruby on mine. All apps point at it. IF I needed more than one, I'd install it into a separate /opt or /local directory hierarchy, and set my PATH for the owning account to point to the needed version. In production that's usually a set once and forget situation.

How to create an RVM environment on a server through net-ssh?

Basically the RVM environment need to be loaded to be able to script it remotely.
https://rvm.io/workflow/scripting/

You can run the following command with net-ssh to do so:

conn.exec!("source "/usr/local/rvm/scripts/rvm; rvm --create ruby-1.9.3-p286@my_project_name")

It will create your environment and associated gemset.

Relationships between Rubygems, Bundler, and RVM

From Bundler's website:

Bundler makes it easy to make sure that your application has the dependencies it needs to start up and run without errors.

This means that it's trivial for some other developer, or you on another machine, to get ready to develop further or use it, by running bundle install and you have everything you need to get up and running.

RVM is for managing multiple versions of Ruby on the same machine, and switching between them. Gemsets is a powerful feature RVM provides that isolates gems for one application/library from the rest of your system.

When using RVM and Bundler together, RVM tells Bundler where the gems should go, and Bundler installs them into the RVM-folder.

Both (with regards to gems in RVMs case) use and depend on Rubygems, so they're closest to wrappers.

I, personally, use Bundler and RVM for all my projects. No gemsets, just Bundler to resolve and fix things, which it does without fail. Installing gems is done without sudo, and ends up in the place RVM defines. The default Ruby install on my system is left alone, and nothing is installed to Rubygems system/user path

bundler vs RVM vs gems vs RubyGems vs gemsets vs system ruby

As per the previous answer, this is quite a lot to cover, so consider this a short introduction.

gems are the way Ruby libraries are packaged. They are to Ruby what jars are to Java. Inside a gem file, you find Ruby code (.rb files), but also tests, and a special file giving information on the gem itself, such as its name, dependencies and version (gemspec). Any Ruby project can define the gems it needs via a Gemfile that just need to declare dependencies. Rubygems is the name of the package manager - the tool used to install the packages (while the gems are the packages themselves). Rubygems is now part of Ruby.

Bundler is what makes managing gems bearable. Based on your Gemfile, a simple call to bundler using bundle install will download and install all the required gems. Using standard gem command, you would have to install each of them manually, using gem install <gem_name>. Bundler is not part of Ruby (it is itself packaged as a gem), but it a "de facto standard" for most applications (you will not find many people not using it, and no good reasons not to use it, actually).

RVM is a tool allowing you to install multiple versions of Ruby on a machine, switching between them when needed. This can be used to install both a Ruby 1.8 and 1.9, or even a "MRI" (Matz's Ruby, the default implementation) and alternatives (such as JRuby or Rubinius). Note that RVM is not alone in this field, see for instance rbenv.

A gemset in RVM is a set of gems specific to a given context, typically a project. This is useful if you are for example developing different applications, each with its own sets of gems, and want to keep them separate.

system Ruby is, when using RVM, the Ruby version installed on the machine (ie, not via RVM).

If you are just starting, gems and bundler are of interest to you. You can let RVM and gemsets aside for now.

Does ruby have real multithreading?

Updated with Jörg's Sept 2011 comment

You seem to be confusing two very different things here: the
Ruby Programming Language and the specific threading model of one
specific implementation of the Ruby Programming Language. There
are currently around 11 different implementations of the Ruby
Programming Language, with very different and unique threading
models.

(Unfortunately, only two of those 11 implementations are actually
ready for production use, but by the end of the year that number
will probably go up to four or five.) (Update: it's now 5: MRI, JRuby, YARV (the interpreter for Ruby 1.9), Rubinius and IronRuby).

The first implementation doesn't actually have a name, which
makes it quite awkward to refer to it and is really annoying and
confusing. It is most often referred to as "Ruby", which is even
more annoying and confusing than having no name, because it
leads to endless confusion between the features of the Ruby
Programming Language and a particular Ruby Implementation.
It is also sometimes called "MRI" (for "Matz's Ruby
Implementation"), CRuby or MatzRuby.
MRI implements Ruby Threads as Green Threads within its
interpreter. Unfortunately, it doesn't allow those threads
to be scheduled in parallel, they can only run one thread at a
time.
However, any number of C Threads (POSIX Threads etc.) can run
in parallel to the Ruby Thread, so external C Libraries, or MRI
C Extensions that create threads of their own can still run in
parallel.
The second implementation is YARV (short for "Yet
Another Ruby VM"). YARV implements Ruby Threads as POSIX or
Windows NT Threads, however, it uses a Global Interpreter
Lock (GIL) to ensure that only one Ruby Thread can actually be
scheduled at any one time.
Like MRI, C Threads can actually run parallel to Ruby Threads.
In the future, it is possible, that the GIL might get broken
down into more fine-grained locks, thus allowing more and more
code to actually run in parallel, but that's so far away, it is
not even planned yet.
JRuby implements Ruby Threads as Native Threads,
where "Native Threads" in case of the JVM obviously means "JVM
Threads". JRuby imposes no additional locking on them. So,
whether those threads can actually run in parallel depends on
the JVM: some JVMs implement JVM Threads as OS Threads and some
as Green Threads. (The mainstream JVMs from Sun/Oracle use exclusively OS threads since JDK 1.3)
XRuby also implements Ruby Threads as JVM Threads. Update: XRuby is dead.
IronRuby implements Ruby Threads as Native Threads,
where "Native Threads" in case of the CLR obviously means
"CLR Threads". IronRuby imposes no additional locking on them,
so, they should run in parallel, as long as your CLR supports
that.
Ruby.NET also implements Ruby Threads as CLR
Threads. Update: Ruby.NET is dead.
Rubinius implements Ruby Threads as Green Threads
within its Virtual Machine. More precisely: the Rubinius
VM exports a very lightweight, very flexible
concurrency/parallelism/non-local control-flow construct, called
a "Task", and all other concurrency constructs (Threads in
this discussion, but also Continuations, Actors and
other stuff) are implemented in pure Ruby, using Tasks.
Rubinius can not (currently) schedule Threads in parallel,
however, adding that isn't too much of a problem: Rubinius can
already run several VM instances in several POSIX Threads in
parallel, within one Rubinius process. Since Threads are
actually implemented in Ruby, they can, like any other Ruby
object, be serialized and sent to a different VM in a different
POSIX Thread. (That's the same model the BEAM Erlang VM
uses for SMP concurrency. It is already implemented for
Rubinius Actors.)
Update: The information about Rubinius in this answer is about the Shotgun VM, which doesn't exist anymore. The "new" C++ VM does not use green threads scheduled across multiple VMs (i.e. Erlang/BEAM style), it uses a more traditional single VM with multiple native OS threads model, just like the one employed by, say, the CLR, Mono, and pretty much every JVM.
MacRuby started out as a port of YARV on top of the
Objective-C Runtime and CoreFoundation and Cocoa Frameworks. It
has now significantly diverged from YARV, but AFAIK it currently
still shares the same Threading Model with YARV.
Update: MacRuby depends on apples garbage collector which is declared deprecated and will be removed in later versions of MacOSX, MacRuby is undead.
Cardinal is a Ruby Implementation for the Parrot
Virtual Machine. It doesn't implement threads yet, however,
when it does, it will probably implement them as Parrot
Threads. Update: Cardinal seems very inactive/dead.
MagLev is a Ruby Implementation for the GemStone/S
Smalltalk VM. I have no information what threading model
GemStone/S uses, what threading model MagLev uses or even if
threads are even implemented yet (probably not).
HotRuby is not a full Ruby Implementation of its
own. It is an implementation of a YARV bytecode VM in
JavaScript. HotRuby doesn't support threads (yet?) and when it
does, they won't be able to run in parallel, because JavaScript
has no support for true parallelism. There is an ActionScript
version of HotRuby, however, and ActionScript might actually
support parallelism. Update: HotRuby is dead.

Unfortunately, only two of these 11 Ruby Implementations are
actually production-ready: MRI and JRuby.

So, if you want true parallel threads, JRuby is currently your
only choice – not that that's a bad one: JRuby is actually faster
than MRI, and arguably more stable.

Otherwise, the "classical" Ruby solution is to use processes
instead of threads for parallelism. The Ruby Core Library
contains the Process module with the Process.fork
method which makes it dead easy to fork off another Ruby
process. Also, the Ruby Standard Library contains the
Distributed Ruby (dRuby / dRb) library, which allows Ruby
code to be trivially distributed across multiple processes, not
only on the same machine but also across the network.

Installing Ruby 1.9.3 Troubles with Clang

Refer to this answer.

Even though both ruby-1.9.3-p125 and ruby-1.9.3-p194 some support for clang, installing Ruby with clang is generally not recommended.

(Note: I had to accept edit proposal first, then edit. Thank you very much for contribution.)

How to install rvm install 2.1.1 on ubuntu 19.04

At this moment, it is no longer possible to install old rubies on recent Ubuntu. If you need to run old rubies, I recommend you stick with Ubuntu 18.04 LTS, on which you can still install any ruby you want.

2.1.x, 2.2.x and 2.3.x no longer installs on 19.04

We would need a custom openssl 1.1 patch, I'm not sure if someone will work on this. Most of the ruby community is ready to move forward.

For production environment you should stick to LTS releases for sure.

When 20.04 LTS comes out, ruby 2.4 will be unsupported by the ruby-core team itself.

https://www.ruby-lang.org/en/news/2019/03/31/support-of-ruby-2-3-has-ended/

From Ubuntu 19.04 and onward, rvm install 2.4.6 is your oldest option,
rvm install 2.6.3 is the current recommended release

On my Ubuntu 18.04 I have

ubuntu@ip-w-x-y-z:~$ rvm list 
   ruby-2.0.0-p648 [ x86_64 ]
   ruby-2.1.8 [ x86_64 ]
   ruby-2.2.10 [ x86_64 ]
   ruby-2.2.4 [ x86_64 ]
   ruby-2.3.8 [ x86_64 ]
   ruby-2.4.6 [ x86_64 ]
=* ruby-2.6.3 [ x86_64 ]

On my 19.04 laptop I have

ubuntu@ip-w-x-y-z:~$ rvm list 
=> ruby-2.4.6 [ x86_64 ]
   ruby-2.5.5 [ x86_64 ]
 * ruby-2.6.3 [ x86_64 ]
   ruby-2.7.0-preview1 [ x86_64 ]

Update for Ubuntu 22.04 -- I could install all rubies from 1.9.3 to 3.1.2

For ruby 2.4.x -> 3.0.4, I used openssl 1.1.1g. You also have the option to compile without SSL and later install the openssl gem, which is automatically compiled with OpenSSL 3.0.

For ruby 1.9.3 -> 2.3.8, I used openssl 1.0.2u. You need to build with the option -fPIC otherwise, it won't build.

Download from there
https://www.openssl.org/source/old/

Extract and build like this.

./config --prefix=~/.openssl/openssl-1.0.2u -fPIC
make && make install
rvm install 2.1.10 --movable --with-openssl-dir=$HOME/.openssl/openssl-1.0.2u

mathieu:openssl-1.0.2u :-) (lifebook-wu2) $ cat /etc/issue.net 
Ubuntu 22.04 LTS
mathieu:openssl-1.0.2u :-) (lifebook-wu2) $ rvm list 
   ruby-1.9.3-p551 [ x86_64 ]
=> ruby-2.0.0-p648 [ x86_64 ]
   ruby-2.1.10 [ x86_64 ]
   ruby-2.2.10 [ x86_64 ]
   ruby-2.3.8 [ x86_64 ]
   ruby-2.4.10 [ x86_64 ]
   ruby-2.5.9 [ x86_64 ]
   ruby-2.6.10 [ x86_64 ]
   ruby-2.6.9 [ x86_64 ]
   ruby-2.7.5 [ x86_64 ]
   ruby-2.7.6 [ x86_64 ]
   ruby-3.0.3 [ x86_64 ]
   ruby-3.0.4 [ x86_64 ]
 * ruby-3.1.2 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

mathieu:openssl-1.0.2u :-) (lifebook-wu2) $

Is Rvm Production Ready