今更だけど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 指定のタイミングは あまり離れない方がよいということか？)
Haskell 環境をローカル(プロジェクト毎)に生成するコマンド hsenv <URL:http://hackage.haskell.org/package/hsenv>。
rbenv & ruby-build を調べたのはついでで、実際はこちらが先。 hsenv は python の virtualenv を参考に作ったとあり、似たようなものに rvm があるなあ、 と見てみると最近は rbenv の方が好まれているらしい。 ということで調べてみたら、結構おもしろかったのでまとめてみた。
hsenv は、最初は rbenv のように ghc の各バージョンや、ghc 以外の Haskell を切り替えて使えるようなツールかと思っていたが、 どちらかというと cabal-dev に近く、 hsenv コマンドを実行したカレントディレクトリに .hsenv/ を生成しその下に必要なパッケージをインストールしていく形。 cabal-dev install ではなく cabal install を使えるように .hsenv/bin/ 以下に ghc, ghci, ghc-mod, runghc, cabal、そしてそれらを有効にする activate を置く。 source activate をしたシェルを使っている間(exit するまで)、 または deactivate_hsenv を実行するまでは、cabal install したパッケージは ~/.cabal/ 以下ではなく .hsenv/cabal/ 以下にインストールされ、system(global) や user へ影響しないようにする。 (※Haskell は The Haskell 2010 report をサポートする実装が ghc しかなく、ビルドも面倒なため、 Python や Ruby と比べ他の実装と切り替えて使用するということが少ないんだろうと思う。)
以下は hsenv の説明から。
まず、Haskell 環境をサンドボックス化したいディレクトリを選ぶ(例えば cabal 化したプロジェクトなど)。 ディレクトリに移動する。
$ cd ~/projects/foo
次に、隔離した Haskell 環境を生成する(環境ごとに1回だけ実行する)。
$ hsenv
あとは、このHaskell 環境を使いたいときに毎回、以下を実行して環境を有効化する。
$ cd ~/projects/foo $ source .hsenv/bin/activate
これで、生成した Haskell 環境に PATH が通り、cabal のインストール先も切り替えるなどする。 cabal でインストールしたパッケージは system(global) や user へ影響しないよう、 ~/projects/foo/.hsenv/cabal 以下にインストールされる。 また、基本的なパッケージのみ(ghc と Cabal、それらが依存するパッケージ)を Haskell 環境にコピーするため、 これらのパッケージ以外の影響も受けない。
Haskell 環境を使い終わったら、以下のコマンドを実行するか、現在のシェルを終了する。
$ deactivate_hsenv
異なる GHC のバージョンを使用することができる。 開発中のコードが違うバージョン(nightly buildも含め)でのテストに使える。
まず、バイナリ配布の GHC を取得して、 以下を実行して新しい Haskell 環境を生成する。
$ hsenv --ghc=/path/to/ghc_something.tar.gz2
あとは、Basic usage 同様にして [de]activation する。
hsenv を調べたのは、penny をインストールしようとしたら、penny-lib が依存している bytestring (0.10.*) と、 既にインストールしている bytestring 0.9.2.1 がコンフリクトしており、--reinstall --force-reinstalls を指定して cabal install を実行する必要があったため。 少しスマートな方法は無いか調べてみた。
調べてみると cabal-dev と同様な仕組みであることが分かった。 実運用上は cabal-dev を使っていればよく、cabal-dev shell のようにして ./cabal-dev/ 以下にインストールしたパッケージやコマンドを実行できればより便利と思われる。 (cabalize する予定のパッケージでも、いろいろ依存関係がある大規模S/Wなら開発(設計)中は hsenv で作って、 必要なパッケージが固まってきたら *.cabal を書いて cabal-dev に移行するのがスマートかもしれない。)
結局 penny-bin パッケージをインストールする場合は、hsenv で作成した Haskell 環境に bytestring が含まれており、 それらに依存している regex-compat, regex-posix, regex-base パッケージをインストールしなおす必要があると cabal に怒られる。そのため、
$ cabal-dev install --force-reinstalls penny-bin
で、必要な cabal パッケージを含めて cabal-dev 以下に配置するしかない。
(隔離環境で hsenv や cabal-dev で新しくパッケージをインストールするのに、 既に system(global) や user にインストールしている(ビルド済みの)パッケージを元に依存関係を生成してエラーを出すのは、 cabal のバグの気がする。)