January 31, 2012 at 13:02When RVM is needed, and when rbenv is enough
In this article I will not go into details of the operation of RVM and rbenv. Information on these gizmos is enough on the Internet. Here I want to try to solve the question: when is it worth using rbenv, and when not?
To do this, let's first understand why RVM was created, and why rbenv. To do this, just look at the capabilities of both systems.
These are all possibilitiesunfortunately fortunately. I want to add from myself that more is not needed.
Since there are a lot of opportunities (everything can be viewed on the official website), here I will give the main ones.
Let us dwell on this. The list will be 2 times larger due to the fact that RVM supports not only manipulations with ruby, but also with gemsets.
When the bundler was not in the world, all the gems needed for the project were put into the system and mixed with the gems used by another project. As a result, we got porridge with various gems of different versions, the project used the gem of the wrong version at startup and crashed, and even worse - it started and did not work as we would like, or the gem was not included in the project at all for unknown reasons. An alternative solution was to freeze them in vendor / , of course , but this solution did not allow updating gems (this had to be done manually), and the project weighed several times more. With the advent of bundler , it became possible to put gems necessary for the project anywhere (for this you need to pass the --path variable to bundle install), and these gems will not affect the work of another project. As a result, we get what RVM does for us - a workhorse for managing gemsets, but for this we do not need RVM!
This is the answer to the main question of this post. Recently, it is difficult to find a project that does not use bundler. If you use bundler in all projects, using RVM makes no sense.
Suppose we have two projects A (rails 3, ruby 1.9.1) and B (rails 2, ruby 1.8.7), rbenv with these versions of ruby is installed on the system. My actions:
It's all. As a result, we have 2 projects with different, non-overlapping sets of gems for different versions of ruby. If we go into project A, we will automatically install ruby 1.9.1 in the shell. When the server starts, ruby 1.9.1 and a set of gems from vendor / bundle will be used .
A huge plus is that we can easily analyze the source code of gems and modify them, if this is of course necessary. I believe the plus is that the source code of all gems will be in the project, and not somewhere else, it is obvious and does not require a detailed explanation and debriefing.
It is rational to use RVM only in one case: if bundler is not used in projects .
goal
To do this, let's first understand why RVM was created, and why rbenv. To do this, just look at the capabilities of both systems.
Rbenv features
- Installing different versions of ruby
- Removing them individually
- Changing the ruby version on the system
- Change ruby version for a specific project
- Installing gems for the current ruby version in the system (more precisely, in the installation path of the current ruby version)
These are all possibilities
RVM Features
Since there are a lot of opportunities (everything can be viewed on the official website), here I will give the main ones.
- Installing different versions of ruby
- Removing them individually
- Install gemsets
- Removing gemsets
- Crossover between ruby versions on a system
- Rollback between gemsets in the system
- Creating a ruby or gemset configuration for a specific project
Let us dwell on this. The list will be 2 times larger due to the fact that RVM supports not only manipulations with ruby, but also with gemsets.
Why are gemsets needed?
When the bundler was not in the world, all the gems needed for the project were put into the system and mixed with the gems used by another project. As a result, we got porridge with various gems of different versions, the project used the gem of the wrong version at startup and crashed, and even worse - it started and did not work as we would like, or the gem was not included in the project at all for unknown reasons. An alternative solution was to freeze them in vendor / , of course , but this solution did not allow updating gems (this had to be done manually), and the project weighed several times more. With the advent of bundler , it became possible to put gems necessary for the project anywhere (for this you need to pass the --path variable to bundle install), and these gems will not affect the work of another project. As a result, we get what RVM does for us - a workhorse for managing gemsets, but for this we do not need RVM!
This is the answer to the main question of this post. Recently, it is difficult to find a project that does not use bundler. If you use bundler in all projects, using RVM makes no sense.
How do I use rbenv
Suppose we have two projects A (rails 3, ruby 1.9.1) and B (rails 2, ruby 1.8.7), rbenv with these versions of ruby is installed on the system. My actions:
- I go on the path of project B
- I perform rbenv local 1.8.7 . This will create a .rbenv-version file and now, when in this directory, the ruby version will be installed from this file
- bundle install --path = vendor / bundle . This will freeze the gems described in the gemfile in the path ./vendor/bundle
- I do the same with project A, installing version 1.9.1
It's all. As a result, we have 2 projects with different, non-overlapping sets of gems for different versions of ruby. If we go into project A, we will automatically install ruby 1.9.1 in the shell. When the server starts, ruby 1.9.1 and a set of gems from vendor / bundle will be used .
A huge plus is that we can easily analyze the source code of gems and modify them, if this is of course necessary. I believe the plus is that the source code of all gems will be in the project, and not somewhere else, it is obvious and does not require a detailed explanation and debriefing.
Why then RVM?
It is rational to use RVM only in one case: if bundler is not used in projects .