目的
これを行うには、まずRVMが作成された理由と、rbenvを作成した理由を理解しましょう。 これを行うには、両方のシステムの機能をご覧ください。
Rbenvの機能
- 異なるバージョンのrubyをインストールする
- それらを個別に削除する
- システムのルビーバージョンを変更する
- 特定のプロジェクトのルビーバージョンを変更する
- システム内の現在のrubyバージョンのgemのインストール（より正確には、現在のrubyバージョンのインストールパス）
RVM機能
多くの機会があるので（すべては公式Webサイトで見ることができます）、ここで主なものを紹介します。
- 異なるバージョンのrubyをインストールする
- それらを個別に削除する
- gemsetsをインストールする
- 宝石セットの削除
- システム上のルビーバージョン間のクロスオーバー
- システム内の宝石セット間のロールバック
- 特定のプロジェクト用にrubyまたはgemset構成を作成する
これについて詳しく見てみましょう。 RVMはrubyによる操作だけでなくgemsetによる操作もサポートしているため、リストは2倍になります。
なぜ宝石セットが必要なのですか？
バンドラーが世界になかったとき、プロジェクトに必要なすべての宝石がシステムに入れられ、別のプロジェクトで使用された宝石と混合されました。 その結果、さまざまなバージョンのさまざまなgemが含まれたおridgeを得ました。このプロジェクトは、起動時に間違ったバージョンのgemを使用してクラッシュし、さらに悪化しました-開始し、希望どおりに動作しなかったか、不明な理由でプロジェクトに含まれていませんでした。 代替ソリューションは、 ベンダー/でそれらをフリーズすることでしたが、このソリューションではgemの更新が許可されず（これは手動で行う必要がありました）、プロジェクトの重量はさらに数倍になりました。 bundlerの登場により、プロジェクトに必要なgemをどこにでも配置できるようになりました（このため、-- path変数をbundle installに渡す必要があります）。これらのgemは別のプロジェクトの作業に影響しません。 その結果、RVMが私たちのために何をするのかを知ることができます-gemsetを管理するための主力製品ですが、このためにはRVMは必要ありません！
これは、この投稿の主な質問に対する答えです。 最近、バンドラーを使用しないプロジェクトを見つけることは困難です。 すべてのプロジェクトでバンドラーを使用する場合、RVMを使用しても意味がありません。
rbenvの使用方法
2つのプロジェクトA（rails 3、ruby 1.9.1）とB（rails 2、ruby 1.8.7）があり、rbenvがこれらのバージョンのrubyと共にシステムにインストールされているとします。 私の行動：
- 私はプロジェクトBの道を進みます
- rbenv local 1.8.7の実行 。 これにより.rbenv-versionファイルが作成され、このディレクトリにあるとき、このファイルからrubyバージョンがインストールされます
- bundle install --path = vendor / bundle これにより、パス./vendor/bundleの gemfileに記述されているgemがフリーズします
- プロジェクトAでも同じことを行い、バージョン1.9.1をインストールします
以上です。 その結果、Rubyのバージョンごとに異なる重複しないgemのセットを持つ2つのプロジェクトがあります。 プロジェクトAに入ると、シェルにruby 1.9.1が自動的にインストールされます。 サーバーが起動すると、ruby 1.9.1とベンダー/バンドルの gemのセットが使用されます。
もちろん、必要な場合は、gemsのソースコードを簡単に分析して変更することができます。 プラスは、すべてのgemのソースコードがプロジェクト内にあり、他の場所ではないことは明白であり、詳細な説明と説明を必要としないことです。
なぜRVMなのか？
RVMを使用するのは理にかなっていますが、それは、プロジェクトでバンドラーが使用されていない場合のみです。