今更だけどrvmからrbenvに乗り換えるときの個人用メモ <URL:http://d.hatena.ne.jp/sandmark/20121122/1353625485>
rbenv & ruby-build の使い方メモ <URL:http://qiita.com/items/b07beebca21ba7ed8e7f>
OS X で rbenv を使って ruby 1.9.3 or 2.0.0 の環境を作る <URL:http://qiita.com/items/9dd797f42e7bea674705>
Rails開発環境の構築（rbenvでRuby導入からBundler、Rails導入まで） <URL:http://qiita.com/items/a60886152a4c99ce1017>
$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv $ mkdir -p ~/.rbenv/plugins $ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
export PATH="$HOME/.rbenv/bin:$PATH" eval "$(rbenv init -)"
設定を反映する。 (※上記設定で $HOME/.rbenv/shims にもPATHが通る。)
以下でインストール可能なRubyの一覧が見れる。
$ rbenv install -l
インストール前に、make のオプションを指定しておく。 一般的にCPUコアの数+1を -j で指定しておくと効率がよい。
$ export MAKEOPTS="-j9"
1.9系の最新版をインストール
$ rbenv install 1.9.3-p392 --verbose
2.0の最新版もインストール
$ rbenv install 2.0.0-p0 --verbose
自分でコンパイルしてインストールする場合は以下の手順。 さくらインターネットのレンタルサーバだと bison が入ってなくて ruby-2.0.0-p0 が コンパイルできず、新しい bison を入れようとすると m4 が古いと怒られたので、 以下のような手順となる。 ($HOME/bin に PATH が通っている前提。 git を素の Makefile でビルドして $HOME/bin 以下にインストールしたため、 他のツールもここに入れてしまうことにする。最近契約するともう少し新しいんだろうか。 事前にデフォルト shell も .login に exec /usr/local/bin/bash -l を書いて bash にしておく(でないと上記の rbenv init が実行できない))
$ cd ~/tmp $ wget http://www.ring.gr.jp/archives/GNU/bison/bison-2.4.3.tar.gz $ tar zxf bison-2.4.3.tar.gz $ cd bison-2.4.3 $ ./configure --prefix=$HOME $ gmake install $ cd .. $ wget http://ftp.ruby-lang.org/pub/ruby/ruby-2.0.0-p0.tar.gz $ tar zxf ruby-2.0.0-p0.tar.gz $ cd ruby-2.0.0-p0 $ mkdir dist $ ../configure --prefix=$HOME/.rbenv/versions/2.0.0-p0c $ gmake $ gmake install
動きとしては1.9と2.0に大きな差は無いので、2.0をデフォルトにする。
$ rbenv global 2.0.0-p0 $ rbenv rehash $ ruby --version ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]
rbenv 導入後は gem install で $HOME/.rbenv/versions/<ruby-version>/lib/ruby/gems 以下にインストールされる。 (rbenv 導入前は $HOME 以下にインストールするため --user を指定する必要がある。)
$ gem install rdtool
生成した実行ファイルを呼び出せるように、gem install 後 rbenv rehash を実行する必要がある。 ($HOME/.rbenv/versions/<ruby-version>/bin 以下にある実行ファイルを呼び出せるように $HOME/.rbenv/shims/ 以下に同名の実行ファイルを生成する)
$ rbenv rehash
これで rd2 コマンドが実行できるようになる。
ついでに nanoc も。
$ gem install nanoc $ rbenv rehash
Bundler とは、Gemfile に必要な rubygems を記述しておくことで、 どこでも bundle install 一発で依存する rubygems をインストールすることができるようにしたもの。
Bundler: The best way to manage a Ruby application's gems <URL:http://gembundler.com/>
bundler は gem でインストール。
$ gem install bundler $ rbenv rehash
Rails 最新版でプロジェクトを開始しようとした場合を例に進める。 一時ディレクトリを作成。
$ mkdir ~/tmp/pj $ cd ~/tmp/pj
必要な rubygems を Gemfile に記述しておく。ここでは rails 最新版を指定。 (※インストールされたのが 3.2.13 だったので、以下はそのバージョンを前提)
source 'http://rubygems.org' gem 'rails'
(※Rails4 はまだリリースされていなかったので、インストールには明示的なバージョン指定が必要。)
source 'http://rubygems.org' gem 'rails', '4.0.0.rc1'
bundle コマンドで vendor/bundle 以下に rails をインストール。
$ bundle install --path vendor/bundle
インストールした rails でプロジェクト <project-name> を作成。 (--skip-bundle を指定しないと、この時点で bundle install が実行されてしまう。)
$ bundle exec rails new <project-name> --skip-bundle
生成したプロジェクトの Gemfile を元に、実際に使用する rubygems を vendor/bundle 以下に インストールする。
$ cd example $ bundle install --path vendor/bundle
(Rails3 の場合) bundle install した rubygems の実行ファイルを実行するには bundle exec <実行ファイル> を 呼び出すが、毎回書くのは面倒なので、bin/ 以下に stub を生成しておく。 こうすると、例えば rspec を bundle でインストールした時に bundle exec rspec ではなく bin/rspec で実行することができる。
$ bundle install --binstubs
(Rails4 の場合) Rails4 から script/ が無くなり、bin/ 以下に bundle, rails, rake が生成されるようになった。 bundle install --binstubs を指定するとこれらが上書きされてしまう。 使用するコマンドについては bundle binstubs <command> で逐一追加する形となる。
$ bundle binstubs rspec
あとは .gitignore に bundle install で生成したファイル／ディレクトリを追加。
/vendor/bundle #/bin # Rails4の変更があるので、bin/ 以下は履歴管理対象としておいた方がよいと思う。
git で履歴管理。
$ git init $ git add . $ git commit -m "initial."
以降、git clone した場合はまず以下のコマンドを実行することで、同じ環境が構築できる。 (Gemfile.lock がある場合(履歴管理対象とした場合)には、そのバージョンも含めて。)
$ bundle install --path vendor/bundle
Gemfile.lock を更新したい場合は bundle update を実行する。
production 環境用には、 bundle install --deployment を実行する。 この指定で、以下のような動作になる。
vendor/bundle 以下に必要な rubygems をインストールする。 Gemfile.lock を更新する。(development 環境と production 環境は必要な rubygems が異なることが多い) (※よく分からないが、bundle package を実行していた場合の動作にも違いがある)
(※Gemfile.lock を更新するということは、bundle update と --deployment 指定のタイミングは あまり離れない方がよいということか？)