Witam
Postanowiłem zainstalować wersję ruby z gita, więc wydałem polecenie ‘rvm install ruby-head’. Chciałem też, żeby ta wersja była domyślną dla przyszłych shelli, zatem kazałem też ‘rvm --default use ruby-head’. Tak więc zadowolony uruchamiam konsolę z projektem rails 3.0.0 i ‘rails s’. No i tu niemiła niespodzianka, bo skrypt wyrzuca
/home/bartek/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/site_ruby/1.9.1/rubygems.rb:779:in `report_activate_error': Could not find RubyGem rails (>= 0) (Gem::LoadError)
from /home/bartek/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/site_ruby/1.9.1/rubygems.rb:214:in `activate'
from /home/bartek/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/site_ruby/1.9.1/rubygems.rb:1082:in `gem'
from <internal:gem_prelude>:213:in `push_gem_version_on_load_path'
from <internal:gem_prelude>:16:in `gem'
from /usr/bin/rails:18:in `<main>'
Czego mi może w konfiguracji brakować, że to nie chce działać?
Właśnie, wiedziałem, że czegoś nie dopowiedziałem. Po kolei. bundle install
instaluje gemy do katalogu projektu, co nie jest zbyt użyteczne, bo rails s
dalej rzuca taki sam błąd. Próbowałem zmigrować gemy poleceniem rvm migrate ruby-1.9.2-rc2 ruby-head
ale to powoduje taki ruch I/O, że proces kswapd0 zajmuje 100% mocy CPU i potrzeba hard-reseta, co jest ewidentnym bugiem w kernelu. Na razi jestem w kropce.
U mnie w podobnej sytuacji pomogło skasowanie rubygems.rb (tzn. oczywiście przemianowanie go na jakieś tam rubygems.bak). W sumie już nie pamiętam dlaczego ale miało to jakieś racjonalne wytłumaczenie…
└─┤06:43 |$├─> gem -v
1.3.7
Zastanawiające jest jeszcze jedno. Dlaczego do czorta system korzysta z katalogu ruby-1.9.2-rc2 gdy powinien korzystać już z ruby-head. Nie ogarniam tego całego rvma, choć muszę przyznać, że bez niego byłoby jeszcze ciężej
Po rubygems.rb -> rubygems.rb.bak
<internal:gem_prelude>:158:in `require': no such file to load -- rubygems (LoadError)
from <internal:gem_prelude>:158:in `load_full_rubygems_library'
from <internal:gem_prelude>:212:in `push_gem_version_on_load_path'
from <internal:gem_prelude>:16:in `gem'
from /usr/bin/rails:18:in `<main>'
Chyba nie jest lepiej.
Musiałem coś strasznie namieszać, bo doinstalowałem gem ‘rails’, potem jeszcze ‘ZenTest’, o którego pluł się autotest, i poszło.
Jeśli nie powiodła się migracja gemów to używając już ruby-head zainstaluj brakujące gemy korzystając z bundle install (bundler domyślnie instaluje gemy w tej samej ścieżce co “gem install”).
Aby zachować porządek możesz później usunąć nieużywaną już wersję rubiego.
No właśnie sęk w tym, że u mnie bundler instaluje je w katalogu projektu, a nie w drzewie RVM. W tym leżał cały problem. Właśnie odkryłem, że można wydać polecenie bundle install --system
, o czym poinformował mnie sam bundler. Ładnie z jego strony. Problem rozwiązany.
Nie śledziłem rozwoju Bundlera od początku, ale obecnie stosowaną praktyką (i polecaną przez twórców Bundlera) jest dodawanie do systemu kontroli wersji wyłącznie plikow Gemfile i Gemfile.lock (same gemy trzymamy poza katalogiem projektu).
Nie zemści się. Po pierwsze jak często instalujesz aplikację? Podpowiedź - rzadko.
Po drugie jak często pada rubygems / gemcutter? Podpowiedź - jw.
W praktyce nie ma z tym problemu :)[/quote]
A jednak
Pamiętam jak kilka miesięcy temu coś dziwnego były jakieś jazdy z rubygems i z niektórych serwerów nie można było się w ogóle połączyć. I trzeba było tłumaczyć klientowi, że padł serwis, z którego korzystają prawie wszyscy programiście rubiego i nie można zrobić deployu.
[quote=phocke]Myślę, że raz na kilka miesięcy to akceptowalna częstotliwość
A Ty drogus jak do tego podchodzisz? Zawsze ściągasz biblioteki do projektu ie. => “bundle package” ??[/quote]
Zależy od projektu. Na niektórych nawet mi się nie chce zmieniać domyślnych ustawień
W tym momencie ustawiałbym coś takiego dla ważnych projektów - szczególnie jeżeli wymagane są częste deploye. Dla mniej ważnych tak jak napisałeś: problem w praktyce nie istnieje
