Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

development:ruby_problems

Probleme mit Ruby-Installationen

Einzelne Gems lassen sich ggf. nur mit gewissen Klimmzügen installieren; primär dann, wenn sie Software voraussetzen, die auf unseren Hosts nicht global zur Verfügung steht, oder nicht in den benötigten Versionen, oder nicht an den entsprechenden Stellen. Wir sammeln an dieser Stelle Workarounds, mit denen du Module, deren Installation auf den ersten Blick problematisch ist, trotzdem installiert bekommst.

Fehlende Schreibrechte

Schlägt eine mit gem install xyz versuchte Installation aufgrund fehlender Schreibrechte fehl (permission denied), versuche es bitte einmal mit gem install xyz --user. Wenn's dann funktioniert, ist dein Uberspace vermutlich etwas älter und hat noch nicht die ~/.gemrc, mit der wir neuere Uberspaces automatisch ausstatten. In unserem Ruby-Artikel beschreiben wir, wie du deine Ruby-Konfiguration updaten kannst; das sollte dieses Problem dauerhaft lösen.

sqlite3

betrifft nur CentOS-5-Systeme

Viele auf Ruby basierende Applikationen, die Datenbanken benutzen, greifen standardmäßig auf SQLite zurück und verwenden dafür das sqlite3-Gem. Allerdings ist die zu CentOS gehörende SQLite-Version 3.3.6 zu alt, um mit neueren Versionen dieses Gems zu harmonieren. Wir haben dir daher unter /package/host/localhost/sqlite-3 eine neuere Version bereitgestellt und in unseren globalen Ruby-1.9- und Ruby-2.0-Installationen das entsprechende Gem für dich schon vorinstalliert. Möchtest du es aber innerhalb deines Uberspaces installieren (beispielsweise, um eine neuere Version des Gems zu verwenden als die, die global vorliegt), musst du gem install mitgeben, wo es die von uns aktualisierte SQLite-Version finden kann. Das funktioniert so:

[helga@amnesia ~]$ gem install --user-install sqlite3 -- \
  --with-sqlite3-include=/package/host/localhost/sqlite-3/include \
  --with-sqlite3-lib=/package/host/localhost/sqlite-3/lib

Ähnlich musst du vorgehen, wenn du Bundler verwenden willst - bundle install will nämlich alle benötigen Gems direkt in deinem Uberspace installieren, und zwar auch jene, die bereits global installiert sind (ja, das soll so sein). Insofern will es auch das sqlite3-Gem noch einmal installieren, nur eben jetzt innerhalb deines Uberspaces. Mit Hilfe von bundle config build.sqlite3 kannst du Bundler aber anweisen, beim Installieren des Gems eben jene neuere SQLite-Installation zu verwenden, und zwar so:

[helga@amnesia MyProjectWithBundler]$ bundle config build.sqlite3 \
  --with-sqlite3-include=/package/host/localhost/sqlite-3/include \
  --with-sqlite3-lib=/package/host/localhost/sqlite-3/lib

Du brauchst das nur einmal zu machen; Bundler merkt sich diese Einstellung in seiner ~/.bundle/config. Anschließend kann ein bundle install auch das neueste SQLite-Gem problemlos installieren.

nokogiri

betrifft nur CentOS-5-Systeme

Nokogiri benötigt eine neuere libxml2 und eine neuere libxslt als die Versionen, die wir global bereitgestellt haben. Mittels toast kannst du dir aber selbstständig neuere Versionen davon in deinem Uberspace installieren und das Nokogiri-Gem dagegen kompilieren. Und so geht's:

[hilde@amnesia ~]$ toast arm libxml libxslt

Installierst du Nokogiri selbst via gem, dann bitte so:

[hilde@amnesia ~]$ gem install --user-install nokogiri -- \
  --with-xml2-lib=$HOME/.toast/armed/lib \
  --with-xml2-include=$HOME/.toast/armed/include/libxml2 \
  --with-xslt-dir=$HOME/.toast/armed

Setzt du eine Applikation ein, die für das Gem-Management auf Bundler setzt, musst du hingegen dessen Konfiguration so anpassen, dass er Nokogiri korrekt für dich baut:

[hilde@amnesia ~]$ bundle config build.nokogiri \
  --with-xml2-lib=$HOME/.toast/armed/lib \
  --with-xml2-include=$HOME/.toast/armed/include/libxml2 \
  --with-xslt-dir=$HOME/.toast/armed

Danke an rbq für den Hinweis auf den von ihm erdachten Workaround!

linecache19

linecache19 benötigt zwingend einige Header der verwendeten Ruby-Version, und zwar welche, die nicht im includes-Verzeichnis von Ruby mitinstalliert werden, sondern ausschließlich im Ruby-Source enthalten sind.

Wenn du nun gem install --user-install linecache19 sagst, schaut das Gem, ob es den Ruby-Source irgendwo findet, und wenn nicht, dann lädt es ein komplette Ruby-Source-Paket aus dem Netz (!) und versucht das nicht etwa in einem temporären Verzeichnis zu entpacken, sondern in einem Unterverzeichnis des bestehenden Ruby-Interpreters (!), wo du natürlich keine Schreibrechte hast - das ist ja der zentral von uns bereitgestellte Interpreter.

http://isitruby19.com/linecache19 liefert hierbei letztlich den entscheidenden Hinweis - man kann sich den Ruby-Source auch selbst runterladen und linecache19 dann sagen, wo es den findet. So geht's, am Beispiel von Ruby 1.9.2-p180:

[hilde@amnesia ~]$ wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz
[hilde@amnesia ~]$ tar -xzvf ruby-1.9.2-p180.tar.gz 
[hilde@amnesia ~]$ gem install --user-install linecache19 -- \
  --with-ruby-include=$HOME/ruby-1.9.2-p180

Wenn du eine andere Ruby-Version verwendest (ruby -v verrät sie dir) musst du natürlich entsprechend jene herunterladen und angeben - das bekommst du schon hin.

Setzt du eine Applikation ein, die für das Gem-Management auf Bundler setzt, musst du hingegen dessen Konfiguration so anpassen, dass er linecache19 korrekt für dich baut:

[hilde@amnesia ~]$ bundle config build.linecache19 \
  --with-ruby-include=$HOME/ruby-1.9.2-p180

Übrigens: Wenn du RVM einsetzt und damit ein eigenes Ruby 1.9 kompiliert hast, hat RVM den Source netterweise vorhanden gelassen. In diesem Fall musst du den Source nicht noch einmal herunterladen, sondern kannst als Pfad statt $HOME/ruby-1.9.2-p180 direkt den Pfad angeben, in dem RVM die Sourcen abgelegt hat - das wäre dann $rvm_path/src/ruby-1.9.2-p180 (auch hier musst du natürlich die Versionsangabe anpassen, wenn du eine andere Ruby-Version verwendest).

rmagick

betrifft nur CentOS-5-Systeme

RMagick ist ein Modul, das ImageMagick an Ruby anbindet. Es verlangt allerdings eine neuere ImageMagick-Version als die, die bei CentOS 5 enthalten ist. Wir stellen dir daher unter /package/host/localhost/ImageMagick eine aktuellere Version bereit.

Problematisch ist, dass man dem RMagick-Gem leider partout nicht sagen kann, wo es ImageMagick findet - es befragt dazu zwangsweise das Programm Magick-config, das dazu im $PATH liegen muss. Aber mit einem Kniff geht's - mit diesen drei Zeilen am Ende in deiner ~/.bash_profile:

[hilde@amnesia ~]$ cat >> ~/.bash_profile <<'__EOF__'
export PATH=/package/host/localhost/ImageMagick/bin:$PATH
export LD_LIBRARY_PATH=/package/host/localhost/ImageMagick/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/package/host/localhost/ImageMagick/lib/pkgconfig:$PKG_CONFIG_PATH
__EOF__

Bitte logge dich anschließend einmal aus und wieder ein, damit diese Variablen in deiner Session entsprechend gesetzt werden. Anschließend lässt sich sich RMagick wie gewohnt mit …

[hilde@amnesia ~]$ gem install --user-install rmagick

… installieren. Für Bundler sollten hier keine Anpassungen nötig sein, da ja keine weiteren Argument für den gem install ...-Aufruf vonnöten sind, die Bundler mitgeteilt werden müssten, und die via .bash_profile gesetzten Umgebungsvariablen auch für Bundler gelten.

patron

betrifft nur CentOS-5-Systeme

Patron ist ein HTTP-Client für Ruby, der auf libcurl basiert. Er verlangt allerdings eine neuere curl-Version als die, die bei CentOS 5 enthalten ist. Wir stellen dir daher unter /package/host/localhost/curl eine aktuellere Version bereit. Du kannst gem wie folgt mitteilen, wo es jene finden kann:

[helga@amnesia ~]$ gem install --user-install patron -- \
  --with-curl-dir=/package/host/localhost/curl

Setzt du eine Applikation ein, die für das Gem-Management auf Bundler setzt, musst du hingegen dessen Konfiguration so anpassen, dass er patron korrekt für dich baut:

[helga@amnesia MyProjectWithBundler]$ bundle config build.patron \
  --with-curl-dir=/package/host/localhost/curl

Du brauchst das nur einmal zu machen; Bundler merkt sich diese Einstellung in seiner ~/.bundle/config. Anschließend kann ein bundle install auch das patron-Gem problemlos installieren.

charlock_holmes

betrifft nur CentOS-5-Systeme

charlock_holmes stellt eine libicu-Anbindung an Ruby dar. Er verlangt allerdings eine neuere libicu-Version als die, die bei CentOS 5 enthalten ist. Wir stellen dir daher unter /package/host/localhost/icu4c eine aktuellere Version bereit. Du kannst gem wie folgt mitteilen, wo es jene finden kann:

[helga@amnesia ~]$ gem install --user-install charlock_holmes -- \
  --with-icu-dir=/package/host/localhost/icu4c

Setzt du eine Applikation ein, die für das Gem-Management auf Bundler setzt, musst du hingegen dessen Konfiguration so anpassen, dass er charlock_holmes korrekt für dich baut:

[helga@amnesia MyProjectWithBundler]$ bundle config build.charlock_holmes \
  --with-icu-dir=/package/host/localhost/icu4c

Du brauchst das nur einmal zu machen; Bundler merkt sich diese Einstellung in seiner ~/.bundle/config. Anschließend kann ein bundle install auch das charlock_holmes-Gem problemlos installieren.

pg

Möchtest du eine eigene PostgreSQL-Installation mit Ruby ansprechen, brauchst du dafür das pg-Gem. Damit dieses allerdings den korrekten Pfad zu dem von uns in /package bereitgestellten PostgreSQL findet, musst du ihm den Pfad zum pg_config-Binary mitgeben. Das funktioniert so:

[helga@amnesia ~]$ gem install --user-install pg -- \
  --with-pg-config=/package/host/localhost/postgresql-${POSTGRESVERSION}/bin/pg_config 

Ähnlich musst du vorgehen, wenn du Bundler verwenden willst. Mit Hilfe von bundle config build.pg kannst du Bundler anweisen, beim Installieren des Gems gegen unser PostgreSQL zu linken, und zwar so:

[helga@amnesia MyProjectWithBundler]$ bundle config build.pg \
  --with-pg-config=/package/host/localhost/postgresql-${POSTGRESVERSION}/bin/pg_config 

Du brauchst das nur einmal zu machen; Bundler merkt sich diese Einstellung in seiner ~/.bundle/config. Anschließend kann ein bundle install auch das neueste pg-Gem problemlos installieren.

development/ruby_problems.txt · Zuletzt geändert: 2015/08/13 00:03 von uber