Wystarczy wyjść poza projekt z bundlerem i wpisać
gem install railties
rbenv exec rails
jak nie chcemy wpisywać rbenv exec to wystarczy rbenv rehash 
Owszem, czyli jak już kiedyś pisałem: po obudowaniu pluginami można rbenv uczynić prawie tak funkcjonalnym jak rvm. Tylko po co?
przy skończonych zasobach czasu i chęci da się wszystkie ficzery RVMa przeportować do rbenva.
Pytanie tylko po co, skoro jest rvm i działa 
//Edit
damn you, Tomash - znowu piszesz to samo co ja, tylko z moim refleksem już coraz gorzej
Owszem, czyli jak już kiedyś pisałem: po obudowaniu pluginami można rbenv uczynić prawie tak funkcjonalnym jak rvm. Tylko po co?[/quote]
Bo nie każdy potrzebuje tych wszystkich bajerów które są w rvm.
Nie każdy też lubi jak przy każdym wykonaniu cd rvm sobie coś tam robi
Naprawdę tylko po to
a teraz przyznaj się, w jaki sposób się o tym dowiedziałeś:
- przeglądałeś kod RVMa, i natrafiłeś na ten bulwersujący, “obnoxious” hack.
- nie przeglądałeś kodu RVMa, ale kiedyś cd nie zadziałał jak powinien, przez “obnoxious” hack rvma - wtedy stwierdziłeś, że rvm ssie i przerzuciłeś się na rbenva
- po przeczytaniu hejtu, który rozpoczął się po wydaniu rbenva
Przy uruchamianiu nowego okna shella bądź zmienianiu katalogu, przełaczanie rubiego czasem chwilkę trwało i to mnie dość irytowało
PS. Co do kodu to tylko rzuciłem na niego okiem.
I nie oślepłeś? ja do tej pory z opaską chodzę
Aliasy tzn co?
U mnie przejście z foo na bundle exec foo było kwestią dodania “b” w kilku aliasach:
alias b='bundle exec'
alias brc='b rails c'
alias capt='b cap test_server:update'
alias pc='b pry -r ./config/environment'
alias th='b thin start &'
alias trc='RAILS_ENV=test b rails c'
alias trp='time b rake parallel:spec'
Sory ale do tej pory poza “emocjonalnymi” wpisami to jak dla mnie jeszcze nikt nie podał sensownego argumentu przeciw rbenv. Jak widzę wszystko tutaj sprowadza się do indywidualnych preferencji dotyczących zarządzania gemami i tyle.
zamiast bunle exec rails polecam script/rails działa troszkę szybciej
[code]~/code/fdb[feature/rails3]% time bundle exec rails r ‘puts 1’
1
bundle exec rails r ‘puts 1’ 4,99s user 0,72s system 99% cpu 5,758 total
~/code/fdb[feature/rails3]% time script/rails r ‘puts 1’
1
script/rails r ‘puts 1’ 3,54s user 0,59s system 99% cpu 4,153 total[/code]
Lokalnie rvm sprawdza się zacnie. Na serwerze prostota ruby-build jest cudna
Sensowny argument jest taki: używam rvm, działa świetnie, używam gemsetów, nie chcę się uczyć jak pospinać rbenv, żeby mieć feature’y, które mam teraz. Jak znajdę coś co mi przeszkadza, to obczaję rbenv.
No i nadeszła ta chwila Wrzuciłem rbenv na jednym z serwerów. Skłoniły mnie do tego kolejne problemy przy ustawianiu capistrano, passengera i rvm. rbenv jest dużo prostszy w działaniu i potrzebuje tylko ustawienia 2 zmiennych środowiskowych (PATH i RBENV_ROOT), co jest dużo proste przy konfiguracji capistrano. Nie potrzeba żadnych dodatkowych narzędzi.
Co do rvm, to nadal go używam lokalnie i będę pewnie używał ze względu na kilka rzeczy, ale w szczególności: w rbenv wkurza mnie, że w katalogu “shims”, tzn. tam gdzie znajdują się “wrappery” na pliki wykonywalne dostarczone przez gemy mogą być też pliki, których tak naprawdę w systemie nie ma. O ile na serwerze mi to zupełnie nie przeszkadza, to lokalnie wolę prostotę rvm. No i czasami używam różnych rzeczy, które rvm dostarcza out of the box, np. gemsety.
Tak z ciekawostek - JetBrains właśnie wydało RubyMine z obsługą pik i rbenv. Ponadto ilość watch/fork na githubie: rbenv=1926/422, rvm=2159/129 . Czyli na dziś projekty maja zbliżoną popularność. Osobiście na produkcji używam RVM od 2-3 lat, jestem zadowolony nie mam powodów do zmiany. O tym cd dowiedziałem się dzisiaj, wg mnie to FUD. Równie dobrze można by się czepiać jądra Linuxa, w którym zapewne nie mało jest hacków, również w Rubym i właściwie w każdym większym oprogramowaniu, które wprowadza kompromisy dla wygody