Why is it worth using RVM instead of rbenv + ruby-build
In contrast to this article . I managed to dig a little bit with rbenv, stumble on a few rakes, and decide to dig deeper. And by the time I came across this article, the translation of which I submit to your review and provide.
Today, there are no longer those who have not heard of RVM or rbenv. As a contributor to RVM development, I thought it was worth finding out what exactly rbenv was doing. Reading the source code gave me an idea of rbenv, and, unfortunately, I did not find any new trick to work in the command line shell. However, I understand how both of these utilities work, and I can find a difference in their work. Both utilities provide the ability to switch the active version of Ruby.
The main difference is the way Ruby switches.
')
For RVM, everything happens at the moment of changing the current directory, only once, and at that very moment all executable files and Ruby gems are available. You can also run this procedure manually.
For rbenv, all Ruby and gem executables are always available in the shell, but they will load the necessary code only in the appropriate context, that is, the calculation happens every time the executable file is launched.
Deeper into details: RVM will spend 60ms on each cd launch, which will be a second of time for 16 directory changes. During the directory change, RVM will set all environment variables to point to the current version of Ruby and the current gemset, allowing them to be separated from other versions of Ruby, gems and executables. You cannot run the executable file that belongs to the gem of another project.
For rbenv, a change of directories does not incur time, that is, in a matter of changing directories rbenv faster. After installing the new gems, you will need 60ms to run rbenv rehash. Changing the current version of Ruby or changing the directory does not change the environment, except for the RBENV_VERSION variable, but each time the executable file is launched, 50ms will be spent wrapping up what file to execute for the current version of Ruby and gemset.
To explain in more detail what exactly rbenv is doing, here is a quote from my post on reddit:
The environment is ready to run executable files in both cases, but slightly differently for the utilities in question:
- there is a difference in the moment of loading the environment. For RVM, you can run 'rvm info', for rbenv there is nothing to run; (approx. actually you can run 'rbenv version')
- for RVM, only selected and necessary Ruby / gem executables will be available in the shell. For rbenv, all executable files will be available, only some of them will not do anything at startup; there is no possibility to check whether the executable file is available in the system, since the check will bump into the wrapper and report about its existence;
- Those who are concerned about the time of loading and executing files will not notice a particular difference, it can only be measured. Delays less than 300ms are not noticeable to the user of the shell (approx. Transl. There is an opinion that 150ms, but both utilities fit into this range too).
The author of rbenv, Sam Stephenson, makes the distinction between utilities, criticizing RVM, let's consider them:
1. The need to load into the shell. On the contrary, the rbenv method with wrappers works by adding a folder to your PATH. RVM also does not need to load into the shell. It allows you to work only by downloading the environment file, which happens only once and allows you to quickly and quickly initialize the current version of Ruby and gemset.
2. Overloads shell commands, such as cd. This is dangerous and can lead to errors. Overload cd is optional. I have searched for a total of almost 8 hours in the last month to find a project that overloads cd - and what do you think? Not found. In any case, RVM provides an opportunity to look at the code that will be executed when you run cd until the moment it is executed and select whether to trust it or not.
3. Has a configuration file. There is nothing to configure other than the version of Ruby you want to use. rbenv can currently set up to 4 shell variables that affect running processes, and there is no configuration file to configure them, they should all be configured in rc files, one for each type of shell you use. (I don’t understand what four variables we are talking about, why we need a configuration file, and how changing a Ruby version in one of the sessions can affect running processes, and why the author does not know that all common shells can use one common file , but opinion is opinion) .
4. Installs Ruby. You can install Ruby yourself, or use ruby-build to automate the process. Over its long existence, RVM has gathered a wealth of knowledge on how to install and manage Ruby versions, including patches for various environments.
5. Manages gemsets. Bundler is the best way to manage application dependencies. If the project does not use Bundler yet, it is possible to install the rbenv-gemset plugin. Using gemsets is optional, but recommended, as it simplifies the separation process. The existence of the rbenv-gemset plug-in only confirms this. Even the mighty Bundler can not always understand the gem's intricate relationships. In addition, it is not always convenient to run Rake by invoking 'bundle exec rake'.
6. Requires Ruby Libraries for Compatibility. The simplicity of rbenv allows you only to keep it in the PATH, nothing else is required. RVM does not require changes in gems and libraries.
...
In response to Sam Stevenson, I will give several counter-arguments against the use of rbenv:
1. Execution of the executable file is 50ms slower than for RVM, so if you use a lot of Ruby calls to executable files, you can get the winnings from RVM.
2. Execution of the executable file does not require the required executable file to be available, it will quietly fail without a single warning that the file is not available.
3. It is impossible to check the presence of one or another executable file in the system; additional tricks are required. With RVM, it’s enough to set up the environment - and everything works in agreement with the UNIX ideology. With rbenv, the same environment is deceived by wrappers.
Summing up, these are two different utilities that allow developers to perform the same task, but in several different ways. Knowing the difference will allow everyone to choose the right tool for their job.
Often referred to is the complexity and size of the RVM. rbenv is a fairly new project, and it is still relatively small and its code is relatively simple. As the number of opportunities grows, so does the complexity of the project. We look forward to how rbenv grows into a great product, while maintaining simplicity, so that both projects can borrow from each other the best.
There is one more thing that has become available to OSX users, this is the official RVM GUI for Jewelery Box , the demand for which has turned out to be great.
Summing up, I would like to note that we are aware that RVM has grown, and some refactoring would not prevent those who are trying to start participating in its development, and also make the source code more readable and supported. We design RVM2 as an extension of SM , another great tool from the same author, Wayne Seguin , which you should definitely look at, and to describe which more than one article will be needed.
We hear our users loudly and clearly, and we have big plans for the future of RVM.
Today, there are no longer those who have not heard of RVM or rbenv. As a contributor to RVM development, I thought it was worth finding out what exactly rbenv was doing. Reading the source code gave me an idea of rbenv, and, unfortunately, I did not find any new trick to work in the command line shell. However, I understand how both of these utilities work, and I can find a difference in their work. Both utilities provide the ability to switch the active version of Ruby.
The main difference is the way Ruby switches.
')
For RVM, everything happens at the moment of changing the current directory, only once, and at that very moment all executable files and Ruby gems are available. You can also run this procedure manually.
For rbenv, all Ruby and gem executables are always available in the shell, but they will load the necessary code only in the appropriate context, that is, the calculation happens every time the executable file is launched.
Deeper into details: RVM will spend 60ms on each cd launch, which will be a second of time for 16 directory changes. During the directory change, RVM will set all environment variables to point to the current version of Ruby and the current gemset, allowing them to be separated from other versions of Ruby, gems and executables. You cannot run the executable file that belongs to the gem of another project.
For rbenv, a change of directories does not incur time, that is, in a matter of changing directories rbenv faster. After installing the new gems, you will need 60ms to run rbenv rehash. Changing the current version of Ruby or changing the directory does not change the environment, except for the RBENV_VERSION variable, but each time the executable file is launched, 50ms will be spent wrapping up what file to execute for the current version of Ruby and gemset.
To explain in more detail what exactly rbenv is doing, here is a quote from my post on reddit:
There is one big drawback in the wrapped method - all executable files and Ruby and gem binary files are always available in the shell, which is not always convenient.
If, for example, HAML is installed for a single version of Ruby, its executable file will be available to all other versions.
The way with wrappers works contrary to the system - to build an abstraction, without respecting the principles of UNIX operation, such as searching for PATH, is the stupefaction of the system (and you).
It is impossible to launch a wrapper / Ruby without rbenv, which is fundamentally necessary for the environment to work as expected. RVM, on the contrary, by default builds the environment so that the system understands how it should work without the intervention of RVM.
The environment is ready to run executable files in both cases, but slightly differently for the utilities in question:
- there is a difference in the moment of loading the environment. For RVM, you can run 'rvm info', for rbenv there is nothing to run; (approx. actually you can run 'rbenv version')
- for RVM, only selected and necessary Ruby / gem executables will be available in the shell. For rbenv, all executable files will be available, only some of them will not do anything at startup; there is no possibility to check whether the executable file is available in the system, since the check will bump into the wrapper and report about its existence;
- Those who are concerned about the time of loading and executing files will not notice a particular difference, it can only be measured. Delays less than 300ms are not noticeable to the user of the shell (approx. Transl. There is an opinion that 150ms, but both utilities fit into this range too).
The author of rbenv, Sam Stephenson, makes the distinction between utilities, criticizing RVM, let's consider them:
1. The need to load into the shell. On the contrary, the rbenv method with wrappers works by adding a folder to your PATH. RVM also does not need to load into the shell. It allows you to work only by downloading the environment file, which happens only once and allows you to quickly and quickly initialize the current version of Ruby and gemset.
2. Overloads shell commands, such as cd. This is dangerous and can lead to errors. Overload cd is optional. I have searched for a total of almost 8 hours in the last month to find a project that overloads cd - and what do you think? Not found. In any case, RVM provides an opportunity to look at the code that will be executed when you run cd until the moment it is executed and select whether to trust it or not.
3. Has a configuration file. There is nothing to configure other than the version of Ruby you want to use. rbenv can currently set up to 4 shell variables that affect running processes, and there is no configuration file to configure them, they should all be configured in rc files, one for each type of shell you use. (I don’t understand what four variables we are talking about, why we need a configuration file, and how changing a Ruby version in one of the sessions can affect running processes, and why the author does not know that all common shells can use one common file , but opinion is opinion) .
4. Installs Ruby. You can install Ruby yourself, or use ruby-build to automate the process. Over its long existence, RVM has gathered a wealth of knowledge on how to install and manage Ruby versions, including patches for various environments.
5. Manages gemsets. Bundler is the best way to manage application dependencies. If the project does not use Bundler yet, it is possible to install the rbenv-gemset plugin. Using gemsets is optional, but recommended, as it simplifies the separation process. The existence of the rbenv-gemset plug-in only confirms this. Even the mighty Bundler can not always understand the gem's intricate relationships. In addition, it is not always convenient to run Rake by invoking 'bundle exec rake'.
6. Requires Ruby Libraries for Compatibility. The simplicity of rbenv allows you only to keep it in the PATH, nothing else is required. RVM does not require changes in gems and libraries.
...
In response to Sam Stevenson, I will give several counter-arguments against the use of rbenv:
1. Execution of the executable file is 50ms slower than for RVM, so if you use a lot of Ruby calls to executable files, you can get the winnings from RVM.
2. Execution of the executable file does not require the required executable file to be available, it will quietly fail without a single warning that the file is not available.
3. It is impossible to check the presence of one or another executable file in the system; additional tricks are required. With RVM, it’s enough to set up the environment - and everything works in agreement with the UNIX ideology. With rbenv, the same environment is deceived by wrappers.
Summing up, these are two different utilities that allow developers to perform the same task, but in several different ways. Knowing the difference will allow everyone to choose the right tool for their job.
Often referred to is the complexity and size of the RVM. rbenv is a fairly new project, and it is still relatively small and its code is relatively simple. As the number of opportunities grows, so does the complexity of the project. We look forward to how rbenv grows into a great product, while maintaining simplicity, so that both projects can borrow from each other the best.
There is one more thing that has become available to OSX users, this is the official RVM GUI for Jewelery Box , the demand for which has turned out to be great.
Summing up, I would like to note that we are aware that RVM has grown, and some refactoring would not prevent those who are trying to start participating in its development, and also make the source code more readable and supported. We design RVM2 as an extension of SM , another great tool from the same author, Wayne Seguin , which you should definitely look at, and to describe which more than one article will be needed.
We hear our users loudly and clearly, and we have big plans for the future of RVM.
Source: https://habr.com/ru/post/131968/
All Articles