Skip to content

Latest commit

 

History

History
54 lines (34 loc) · 2.75 KB

setup.md

File metadata and controls

54 lines (34 loc) · 2.75 KB

環境構築

まず、プログラミングを始めるまでの環境構築を比較してみましょう。

Ruby の場合

Rubyの場合は、apt などのOSが用意したパッケージは古いので、 rbenvrvm などのバージョンマネージャを使うことがほとんどです。 手元のマシンや、デプロイ先も(たとえ使う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 などが一括インストールできます。

さて、これで本当に環境構築は楽になったのでしょうか。

Footnotes

  1. 最近はDockerの場合も増えてきた

  2. このため共有型レンタルサーバでRubyを使うのは絶望的だった