これまで、RVMやrbenvについて聞いたことがない人はいません。 RVMの開発への貢献者として、rbenvが何をしていたかを理解する価値があると思いました。 ソースコードを読むとrbenvのアイデアが得られましたが、残念ながら、コマンドラインシェルで動作する新しいトリックは見つかりませんでした。 ただし、これらのユーティリティの両方がどのように機能するかを理解しており、それらの機能の違いを見つけることができます。 どちらのユーティリティも、Rubyのアクティブバージョンを切り替える機能を提供します。
主な違いは、Rubyの切り替え方法です。
RVMの場合、現在のディレクトリを変更した時点ですべてが一度だけ発生し、その時点ですべての実行可能ファイルとRuby gemが利用可能になります。 この手順を手動で開始することもできます。
rbenvの場合、すべてのRubyおよびgem実行可能ファイルは常にシェルで使用できますが、適切なコンテキストでのみ必要なコードをロードします。つまり、実行可能ファイルが起動されるたびに計算が行われます。
より詳細：RVMは、CDの実行ごとに60ミリ秒を費やします。これは、ディレクトリの変更が16回行われるのに数秒かかります。 ディレクトリの変更時に、RVMはすべての環境変数を設定して、現在のバージョンのRubyおよび現在のgemsetを指すようにし、他のバージョンのRuby、gem、および実行可能ファイルから分離できるようにします。 別のプロジェクトのgemに属する実行可能ファイルを実行することはできません。
rbenvの場合、ディレクトリの変更には時間がかかりません。つまり、ディレクトリの変更に関しては、rbenvの方が高速です。 新しいgemをインストールした後、rbenv rehashの実行には60msかかります。 Rubyの現在のバージョンを変更したり、ディレクトリを変更しても、変数RBENV_VERSIONを除いて環境は変わりませんが、実行可能ファイルを実行するたびに、Rubyおよびgemsetの現在のバージョンで実行する必要があるファイルの種類をラッパーで計算するのに50ミリ秒かかります。
rbenvの正確な機能をさらに詳しく説明するために、redditに関する私の投稿からの引用を以下に示します。
ラッパーメソッドには1つの大きな欠陥があります。Rubyとgemのすべての実行可能ファイルとバイナリは常にシェルで利用できますが、これは必ずしも便利ではありません。
たとえば、HAMLがRubyの1つのバージョン用にインストールされている場合、その実行可能ファイルは他のすべてのバージョンで使用できます。
ラッパーメソッドはシステムとは反対に機能します-PATHでの検索など、UNIXの原則を尊重せずに抽象化を構築するために、これは馬鹿げたシステム（およびあなた）です。
rbenvなしで/ Rubyラッパーを実行することはできません。これは、環境が期待どおりに機能するために基本的に必要です。 一方、RVMはデフォルトで環境を構築するため、RVMの介入なしにシステムがどのように動作するかを理解できます。
環境は両方のケースで実行可能ファイルを実行する準備ができていますが、問題のユーティリティでは若干異なります。
-環境のロードの瞬間に違いがあります。 RVMの場合、「rvm info」を実行できます。rbenvの場合、開始するものはありません。 （約perev。実際には「rbenvバージョン」を実行できます）
-RVMの場合、選択された必要なRuby / gem実行可能ファイルのみがシェルで使用可能になります。 rbenvの場合、すべての実行可能ファイルが使用可能になりますが、起動時には何も実行されないファイルもあります。 チェックがラッパーに実行され、その存在を報告するため、実行可能ファイルがシステムで利用可能かどうかをチェックする方法はありません。
-ファイルのダウンロードと実行時間を心配している人は、大きな違いに気付かないでしょう、それは測定することができるだけです。 300ミリ秒未満の遅延はシェルユーザーには気付きません（約150ミリ秒と考えられていますが、どちらのユーティリティもこの範囲に収まります）。
Sam Stevensonのrbenvによって、ユーティリティ間の区別が提供され、RVMが批判されています。
1. シェルにロードする必要。 対照的に、rbenvラッパーメソッドは、PATHにフォルダーを追加することで機能します。 RVMはシェルにロードする必要もありません。 環境ファイルをロードするだけで作業できます。これは1回だけ発生し、Rubyとgemsetの現在のバージョンを1回迅速かつ迅速に初期化できます。
2. cdなどのシェルコマンドをオーバーロードします。 これは危険であり、エラーにつながる可能性があります。 cdのオーバーロードはオプションです。 先月、合計8時間近くかけてCDをオーバーロードしたプロジェクトを探しましたが、どう思いますか？ 見つかりません。 いずれの場合でも、RVMは、cdが実行されるまで実行されるときに実行されるコードを確認し、それを信頼するかどうかを選択する機能を提供します。
3. 構成ファイルがあります。 使用するRubyのバージョン以外に設定するものはありません。 rbenvは現在、実行中のプロセスに影響を与える最大4つのシェル変数を設定でき、それらを構成する構成ファイルはありません。それらはすべて、使用するシェルのタイプごとに1つのrcファイルで構成する必要があります。 （約transl。4つの変数が何であるか、構成ファイルが必要な理由、セッションの1つでRubyバージョンを変更すると実行中のプロセスにどのように影響するか、すべてのシェルに1つの共通ファイルを使用できることを作者が知らない理由を理解していないしかし意見は意見です） 。
4. Rubyをインストールします。 Rubyを自分でインストールするか、ruby-buildを使用してプロセスを自動化できます。 RVMは、その長い間存在する間に、さまざまな環境用のパッチを含むRubyのバージョンをインストールおよび管理する方法についてかなりの知識を集めてきました。
5. 宝石セットを管理します。 Bundlerは、アプリケーションの依存関係を管理する最良の方法です。 プロジェクトがまだBundlerを使用していない場合は、rbenv-gemsetプラグインをインストールできます。 gemsetsの使用はオプションですが、分離プロセスが簡素化されるため推奨されます。 rbenv-gemsetプラグインの存在自体がこれを確認するだけです。 強力なBundlerでさえ、宝石の複雑な関係を常に把握できるとは限りません。 さらに、 'bundle exec rake'を呼び出してRakeを実行することは必ずしも便利ではありません。
6. 互換性のためにRubyライブラリに含める必要があります。 rbenvのシンプルさは、PATHに保持することのみを可能にし、他には何も必要ありません。 RVMでは、gemとライブラリを変更する必要はありません。
...
サムスティーブンソンへの回答として、rbenvの使用に対するいくつかの反論を示します。
1.実行可能ファイルの実行はRVMの場合よりも50ミリ秒遅いため、Ruby実行可能ファイルへの呼び出しを多く使用する場合、RVMで勝つことができます。
2.実行可能ファイルの実行には、目的の実行可能ファイルが利用可能である必要はありません。ファイルが利用可能でないことを警告することなく静かに失敗します。
3.システム内の1つまたは別の実行可能ファイルの存在を確認することは不可能であり、追加のトリックが必要です。 RVMを使用すると、環境を設定するだけで十分です。すべてがUNIXのイデオロギーと調和して機能します。 rbenvを使用すると、ラッパーによって環境がだまされます。
要約すると、これらは、開発者が同じタスクをわずかに異なる方法で実行できるようにする2つの異なるユーティリティです。 違いを知ることで、誰もが自分の仕事に適した適切なツールを選択できるようになります。
RVMの複雑さとサイズがよく言及されます。 rbenvはかなり新しいプロジェクトであり、これまでのところ比較的小さく、そのコードは比較的単純です。 機会の数が増えると、プロジェクトの複雑さも増します。 rbenvがどのように優れた製品に成長し、シンプルに保ち、両方のプロジェクトがお互いから最高のものを借りられるかを楽しみにしています。
OSXのユーザーが利用できるようになったもう1つのものがあります。これは、RVMの公式GUIであるJewellery Boxです。
要約すると、RVMが成長していることを認識しており、リファクタリングによって開発に参加しようとしている人たちを妨げたり、ソースコードを読みやすく保守しやすくしたりすることはできません。 RVM2は、同じ著者であるWayne Seguinによるもう1つの優れたツールであるSMの拡張として設計しています。
ユーザーの声をはっきりと聞き、RVMの将来について大きな計画を立てています。