When need RVM, and when enough rbenv
In this article I will not go into details of the work of RVM and rbenv. Information on these gizmos is enough on the Internet. Here I want to try to solve the question: when should I use rbenv, and when not?
To do this, let's begin to understand for what 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 so many opportunities (everything can be viewed on the official website), here I will give the main ones.
On this dwell. The list will be 2 times larger due to the fact that RVM supports not only manipulations with ruby, but also with gemessets.
When the bundler was not in the world, all the gems needed for the project were put in the system and mixed with the gems used by another project. As a result, we received porridge with different gems of different versions, the project used the gems of the wrong version when starting and fell, otherwise it got worse and started and did not work as we would like, or the gem was not included in the project for no apparent reason. An alternative way to solve it was of course to freeze them in vendor / , 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 the bundler , it became possible to set the gems needed for the project anywhere (to do this, pass the --path variable to the bundle install ), and these gems will not affect the work of another project. As a result, we get what RVM does for us - the work horse for managing gemsets, but for this we don’t 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 the bundler in all projects, using RVM loses meaning.
Suppose we have two projects A (rails 3, ruby 1.9.1) and B (rails 2, ruby 1.8.7), rbenv is installed in the system with these versions of ruby. My actions:
It's all. As a result, we have 2 projects with different, not intersecting, sets of gems for different versions of ruby. If we enter project A, we will automatically install ruby 1.9.1 in the shell. When starting the server, ruby 1.9.1 and a set of gems from vendor / bundle will be used.
A huge plus is that we can analyze the source code of gems without any problems and modify them if necessary. I think the plus is that the source code of all the gems will be in the project, and not somewhere there, is obvious and does not require a detailed explanation and debriefing.
Rational use of RVM is obtained only in one case: if projects do not use a bundler .
purpose
To do this, let's begin to understand for what RVM was created, and why rbenv. To do this, just look at the capabilities of both systems.
Rbenv features
- Installing different versions of ruby
- Deleting them individually
- Changing the version of ruby in the system
- Change ruby version for a specific project
- Installing gems for the current version of ruby into the system (more precisely, into the installation path of the current version of ruby)
')
These are all possibilities
RVM features
Since there are so many opportunities (everything can be viewed on the official website), here I will give the main ones.
- Installing different versions of ruby
- Deleting them individually
- Gemset installation
- Gemset removal
- Overlap between ruby versions in the system
- Overlap between gemsets in the system
- Creating a ruby or gemset configuration for a specific project
On this dwell. The list will be 2 times larger due to the fact that RVM supports not only manipulations with ruby, but also with gemessets.
Why do we need gem sets?
When the bundler was not in the world, all the gems needed for the project were put in the system and mixed with the gems used by another project. As a result, we received porridge with different gems of different versions, the project used the gems of the wrong version when starting and fell, otherwise it got worse and started and did not work as we would like, or the gem was not included in the project for no apparent reason. An alternative way to solve it was of course to freeze them in vendor / , 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 the bundler , it became possible to set the gems needed for the project anywhere (to do this, pass the --path variable to the bundle install ), and these gems will not affect the work of another project. As a result, we get what RVM does for us - the work horse for managing gemsets, but for this we don’t 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 the bundler in all projects, using RVM loses meaning.
How i use rbenv
Suppose we have two projects A (rails 3, ruby 1.9.1) and B (rails 2, ruby 1.8.7), rbenv is installed in the system with these versions of ruby. My actions:
- I go in project B
- I execute rbenv local 1.8.7 . This will create a .rbenv-version file and now, when it is 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, not intersecting, sets of gems for different versions of ruby. If we enter project A, we will automatically install ruby 1.9.1 in the shell. When starting the server, ruby 1.9.1 and a set of gems from vendor / bundle will be used.
A huge plus is that we can analyze the source code of gems without any problems and modify them if necessary. I think the plus is that the source code of all the gems will be in the project, and not somewhere there, is obvious and does not require a detailed explanation and debriefing.
Why then RVM?
Rational use of RVM is obtained only in one case: if projects do not use a bundler .
Source: https://habr.com/ru/post/137333/
All Articles