まず、プログラミングを始めるまでの環境構築を比較してみましょう。
Rubyの場合は、apt
などのOSが用意したパッケージは古いので、
rbenv
や rvm
などのバージョンマネージャを使うことがほとんどです。
手元のマシンや、デプロイ先も(たとえ使うRubyのバージョンが1つでも)基本的にバージョンマネージャを使います1。
バージョンマネージャを使う利点は、処理系のバージョンが変更しやすいことだけではありません。
$HOME
以下で完結している- 複数環境が共存する仕組みが整えられている
- インストールが自動化されている
特に、ユーザの所有物として処理系がインストールできるのは革命的でした。
昔は bundler
がなかったので、gemをプロジェクト内の vendor/bundle
にインストールするようなことはできなかったのです。
昔々、人類がまだパッケージでインストールした /usr/bin/ruby
などを使っている時代、 人々はgemをインストールするのに、
sudo gem install rails
のように 管理者権限が必要だった のです2。 今では、
gem install rails
とやれば $HOME/.rbenv
以下にインストールされるようになっています。
実は apt
のRubyを使いたくない理由のひとつは、バージョンの古さというより、このあたりの取り回しの悪さにあります。
それ以前に、同じようなことをしたい場合、ソースコードをダウンロードし、 自力でコンパイルする必要がありました。
$ ./configure --prefix $HOME/ruby-2.6.5
$ make
$ make install
もちろん、これだけではバージョンを切り替える仕組みはありません。
バージョンマネージャを使うことで、何も面倒なことを考えること無く、 望むバージョンのRubyがすぐに手に入る のです。
rbenv
の成功によって、他の多くの言語にも *env
が作られました。
世はまさに大*env時代、 様々な *env
を一括管理できる anyenv というものまで生まれ、 今後は(rbenvを含めて) anyenv
を通して色々な言語をインストールするのが主流になるでしょう。
rubyはもちろん, node, python, go, php などが一括インストールできます。
さて、これで本当に環境構築は楽になったのでしょうか。