QA@IT
«回答へ戻る

強調表示を修正

1138
 自分で調べたのでまとめます。
 
-どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと**RVMは全部入りの高機能**、**rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ**というところ。
+どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと **RVMは全部入りの高機能** 、 **rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ** というところ。
 
 rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:
 

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと RVMは全部入りの高機能rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ というところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

  • RVMにはgemsetsという機能があり、使うgem群をプロジェクトごとに切り替えられる
  • RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
  • RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、ruby-buildという別ツールを使う)
  • rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
  • RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと **RVMは全部入りの高機能** 、 **rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ** というところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

- RVMには[gemsets](http://beginrescueend.com/gemsets/basics/)という機能があり、使うgem群をプロジェクトごとに切り替えられる
- RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
- RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、[ruby-build](https://github.com/sstephenson/ruby-build)という別ツールを使う)
- rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
- RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

~~~
$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore
~~~

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

- http://route477.net/d/?date=20120203
- http://www.ginzametrics.com/rvm-bundler-in-five-seconds.html
- http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/
- http://www.rubyinside.com/rbenv-a-simple-new-ruby-version-management-tool-5302.html

全角カッコを半角に

1138
 - RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
 - RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、[ruby-build](https://github.com/sstephenson/ruby-build)という別ツールを使う)
 - rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
-- RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)
+- RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)
 
 RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。
 

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうとRVMは全部入りの高機能rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチというところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

  • RVMにはgemsetsという機能があり、使うgem群をプロジェクトごとに切り替えられる
  • RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
  • RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、ruby-buildという別ツールを使う)
  • rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
  • RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと**RVMは全部入りの高機能**、**rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ**というところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

- RVMには[gemsets](http://beginrescueend.com/gemsets/basics/)という機能があり、使うgem群をプロジェクトごとに切り替えられる
- RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
- RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、[ruby-build](https://github.com/sstephenson/ruby-build)という別ツールを使う)
- rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
- RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

~~~
$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore
~~~

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

- http://route477.net/d/?date=20120203
- http://www.ginzametrics.com/rvm-bundler-in-five-seconds.html
- http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/
- http://www.rubyinside.com/rbenv-a-simple-new-ruby-version-management-tool-5302.html

回答を投稿

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうとRVMは全部入りの高機能rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチというところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

  • RVMにはgemsetsという機能があり、使うgem群をプロジェクトごとに切り替えられる
  • RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
  • RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、ruby-buildという別ツールを使う)
  • rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
  • RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

自分で調べたのでまとめます。

どちらもRubyのバージョン切り替えに使うツール。歴史的にはRVMが先にあってデファクトとなり、その後、より軽量なrbenvが登場した。大雑把にいうと**RVMは全部入りの高機能**、**rbenvは単機能で別ツールやプラグインの利用が必要になることもあるというモジュラーなアプローチ**というところ。

rbenvとRVMの違いと、そのメリット・デメリットを列挙すると:

- RVMには[gemsets](http://beginrescueend.com/gemsets/basics/)という機能があり、使うgem群をプロジェクトごとに切り替えられる
- RVMはシステムワイド、ユーザー単位、プロジェクト個別で設定ファイル(rvmrc)を利用できる。.rvmrcファイルをプロジェクトやホームディレクトリに置いておくと、cdでディレクトリを変更したときにRubyのバージョンやgemsetを切り替えられる。シェルのcdコマンドを上書きしてシェルスクリプトを実行しているので、切り替えのときにrvmrcファイルを信頼するかと聞かれるなど、運用が面倒で実装のクリーンさに欠ける印象
- RVM自体がRubyのビルド機能を持ち、JRubyやRubiniusといった処理系もソースコードをフェッチしてコンパイルしてくれる。このときのビルドオプションもrvmrcに設定しておける(rbenvは自分でビルドするか、[ruby-build](https://github.com/sstephenson/ruby-build)という別ツールを使う)
- rbenvの設定ファイルに書くのはRubyのバージョンだけ。Rubyのバージョン切り替えだけが目的なら十分
- RVMはBundlerやCapistranoといったツールとの連携で個別対処必要な場面もある(https://rvm.beginrescueend.com/integration/bundler/ https://rvm.beginrescueend.com/integration/capistrano/)

RVMのgemsetsは、デフォルトのgem群への汚染を避けてアプリ個別のgemを隔離するために使われてきたが、これは不要だという指摘がある(http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/ )。bundle installに--pathオプションを付けることで、以下のように、いわゆるgemのベンダライズができるから。

~~~
$ bundle install --path vendor
$ echo 'vendor/ruby' >> .gitignore
~~~

上記のコマンドで、プロジェクトのgemはvendor/ruby以下に入る。さらに ‵bundle cache‵ しておくと、bundle installの動作が速くなるし、万が一リポジトリから特定のgemが消えても問題がないという。

(参考)

- http://route477.net/d/?date=20120203
- http://www.ginzametrics.com/rvm-bundler-in-five-seconds.html
- http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/
- http://www.rubyinside.com/rbenv-a-simple-new-ruby-version-management-tool-5302.html