Dla osób, które chcą w szybki sposób skonfigurować działające środowisko railsów zamieszczam poniżej howto, które przeprowadzi was przez instalacje i konfigurację w parę minut (dla systemów w wersji Debian 5.0 Lenny oraz Ubuntu 8.04 Hardy LTS instalacje są takie same):
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar -zxvf rubygems-1.3.1.tgz
cd rubygems-1.3.1
su
ruby setup.rb
ls -s /usr/bin/gem1.8 /usr/bin/gem
3. Instalujemy za pomocą gemów najnowsze railsy (na słabych maszynach ze słabym łączem musimy się uzbroić w cierpliwość)(uprawnienia administracyjne) Kod:
gem install rails
Tworzymy przykładową aplikacje testową (-d mysql oznacza, że będziemy używali bazy danych mysql, dla postgresa jest to postgresql) Kod:
rails -d mysql app
Logujemy się do bazy danych i tworzymy potrzebną nam bazę danych: Kod:
cd app
cat config/databases.yml | grep database:
dostając w wyniku 3 bazy danych (do celów testowych wystarczy nam pierwsza)
database: app_development
database: app_test
database: app_production Kod:
mysql>create database app_development;
Generujemy przykładowego scaffold-a, wykonujemy migrację do bazy i uruchamiamy serwer Kod:
[quote=make]2. Ściągamy i instalujemy paczkę rubygems Kod:
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar -zxvf rubygems-1.3.1.tgz
cd rubygems-1.3.1
su
ruby setup.rb
ls -s /usr/bin/gem1.8 /usr/bin/gem
[/quote]
A jak ktoś nie lubi robić Slacka/Gentoo z Debiana to może użyć http://debs.ciemnogrod.eu/debian/rubygems-1.3.1/
Kłócił się tu kto ma fajniejsze zabawki nie będę ale chodziło mi o ewentualne późniesze “wysprzątanie” - emerge ma sensowną opcję do usunięcia tego co wcześniej zainstalował?
Po instalacji ze źródeł, bez pośrednictwa managera pakietów nie ma takiej możliwości i trzeba ręcznie. Pół biedy, jesli leży wszystko w jednym katalogu i nie zależą od tego inne rzeczy.
Dlatego używając jakiejkolwiek dystrybucji z pakietami, należy trzymać się softu w pakietach.
Z tego samego powodu strasznie mi się nie podobają GEMy jako takie - straszny bajzel, chaos, brak reguł i spójności. Szkoda że nikt tego nie przemyślał, i nie przygotował czegoś na kształt perlowego CPANa.
Sensownie napisane pakiety mają make-taska “uninstall”. No a skoro już zainstalowaliśmy ze źródeł, to fajnie i kształcąco czasem rzucić na nie okiem – wystarczy więc trzymać w np. /usr/local/src wszystko, co instalujemy ze źródeł, a deinstalacja będzie równie skomplikowana co “Make uninistall”
Nie każdy soft dostepny w źródłach ma target uninstall w Makefile, nie każdy który go ma sprząta wszystko. A już na 100% nie rozwiązuje nam to problemu zależności (co jeśli odinstalujesz soft, dajmy na to liba, od którego zależy coś innego?). Menażer pakietów pilnuje tego, trzyma informacje o zależnościach - przez co nie musisz się martwić. No i to jest własnie to o czym pisałem wyżej - po co używać systemu w pakietach, skoro potem kompilujesz większość ze źródeł?
A budowanie pakietów ze źródeł w przypadku dystrybycji z rodziny Debiana jest bardzo proste i można je sprowadzić do kilku przypadków:
do sources.lists dopisujemy deb-src sida - i zbudowanie pakietu w nowszej wersji niż mamy to apt-get build-dep pakiet; apt-get -b source pakiet
wariant powyższego, kiedy zależności w paczce źródłowej nie są spełnione - czasem buduje się je, czasem wystarczy poprawić control albo rules i zbudować bez zależności od sida
wersja której nie ma w sidzie - bierzemy tą co jest, przenosimy katalog debian, poprawiamy changelog i ewentualnie control - próbujemy skompilować - czasem potrzebne są poprawki, czasem nie.
Zbudowanie debów z rubygems w wesji 1.3.1 za pomocą metody 3 zabrało mi jakieś 15 minut.
Jest jeszcze sytuacja, kiedy przekracza to możliwości średnio rozgraniętego developera, albo nie opłaca się czasowo - wtedy można skompilować ze źródeł - ale należy z tym bardzo uważać i mieć świadomość konsekwencji.
Underley, ja się absolutnie zgadzam z Tobą że jeśli można z paczki dystrybucyjnej, to należy z paczki (nawet pomimo tego, że debianowa/ubuntowa paczka Ruby daje interpreter o połowę wolniejszy ) w 99% przypadków. Pozostaje jednak ten 1% (agresywna optymalizacja, konkretny setup) oraz pakiety, których – niestety – nie ma dostępnych w formie .deb (chociaż coraz częściej autorzy i fani przygotowują paczki i za to im chwała).
Na maszynce developera to żaden problem. A na serwerze - można zbudować własnego deba lekko zmieniając opcje configure w debian/rules.
No i zawsze można zgłosić buga, że takie opcje kompilacja jak obecnie powodują znaczny spadek wydajności. (BTW - sprawdzał ktoś jak to wygląda w Lennym?)
Przygotowywanie paczek nie jest trudne - szczególnie jeśli budowanie softu oparte jest o autoconf/automake.
Żeby jeszcze był dla gemów taki bajer jak dh-make-perl, to życie byłoby piękniejsze Może ktoś się pokusi, żeby coś takiego napisac?
ale chodziło mi o ewentualne późniesze “wysprzątanie” - emerge ma sensowną opcję do usunięcia tego co wcześniej zainstalował?
) w 99% przypadków. Pozostaje jednak ten 1% (agresywna optymalizacja, konkretny setup) oraz pakiety, których – niestety – nie ma dostępnych w formie .deb (chociaż coraz częściej autorzy i fani przygotowują paczki i za to im chwała).