gem, require_gem, require ?

Ruby ist eine nette Sache. Irgendwie. Oder um es mit den Worten von Derek Sivers zu sagen:

Programming languages are like girlfriends: the new one is better because *you* are better

Nun, ok. Einerseits kann man sagen das solche Sprüche von ziemlich einsamen, einsamen, einsamen Mitmenschen kommen. Andererseits … es stimmt.

Und je interessanter etwas wird, desto mehr stören einen eventuell die Kleinigkeiten. So wie mich gerade, als ich über eine kleine Hürde in Ruby/Rails/ActiveRecord stolperte.

gem kennt jeder, oder? Schon, klar. gem ist einerseits ein netter Manager um diverse Ruby-Module(?) fein zu verwalten. Andererseits ist gem auch der rechtmässige Befehlsnachfolger von require_gem. Und hier kommt was, woran man sich so als eingefleischter PHP-Entwickler gewöhnen muss: beide Befehle, obwohl der eine auf den anderen aufbaut, und auch interpreterseitig die entsprechenden Hinweise kommen, gem anstatt require_gem zu nutzen, vollführen völlig unterschiedliche Operationen.

require_gem “gem_name” “*version”

… sucht nach einem Modul gem_name, initialisiert/aktiviert und lädt es. Wurde dazu noch *version mit angegeben, wird die spezifische Version des Moduls aktiviert und geladen.

Aktiviert bedeutet hier, das der interne Pfad zu einem bestimmten Modul einer bestimmten Version gesetzt wird.

Laden dagegen bedeutet, das einem Skript die derzeit aktivierte Version von gem_name dann tatsächlich zur Verfügung gestellt wird.

Toll. Und so einfach, nicht?

Beispiel (anhand meines aktuellen Falles):

require_gem “activerrecord”, “=1.15.5”

Modul ActiveRecord in Version 1.15.5 wird aktiviert, dessen Inhalte dem Skript zur Verfügung gestellt. Yipiii.

Aber, dieser Befehl ist derzeit (Stand 0.9.4(gem)) veraltet und wird durch tolle “Warning: require_gem is obsolete. Use gem instead.”-Meldungen signalisiert.

Also ran an …
gem “gem_name” “*version”

gem macht nun … nicht ganz das gleiche. Und das war ein Punkt der mich etwas wuschig machte. gem aktiviert nur das angeforderte Modul (in Version X), stellt dieses aber dem Skript nicht bereit. Ã„rgerlich, aber das Leben ist nunmal kein Ponyhof. Also ran an Google zur Lösungsfindung und vÃ³ila, da war sie nach kurzer Zeit schon.

Da ist schön (mit Hilfe der offiziellen Doku natürlich) erklärt, was Sache ist. Also fehlt .. hmm, ein zusätzliches require, richtig?

Also ran an die Wurst:

gem “activerecord”

require “activerecord”

Hinweis: Ich habe hier mal die Versionsangabe weggelassen. Ohne diese, wird auf die (wohl?) aktuellste Version im lokalem gem-Archiv zurückgegriffen.

Nun, das zustzliche require ist irgendwo verständlich, so geht die gem-Moduleinbindung nichtmehr an der Ruby-Kernmethodik vorbei, sondern bindet stattdessen durch diese Aufteilung, diese in dem Prozess (seitens des Anwenders) lediglich mit ein. Aber klappen tut es trotzdem nicht so recht.

Was hab ich da vergessen? .. *wussel* .. *such* .. aaahh, da steht es ja. Die Bezeichnungen von gem_name und die der ruby-Datei unterscheiden sich :/. Ja toll.

Ergo noch ein …
require “filename”

Damit sieht der Originalcodeschnippsel

require_gem “activerecord” “=1.15.5”

Nun, nach der evolutionären Weiterentwicklung nun so aus:

gem “activerecord” “=1.15.5”

require “active_record”

Also eigentlich find ich das eine sehr interessante Herangehensweise, immerhin muss das gesamte Projekt von vornherein mit mehreren Testcases umschlossen sein, um bei solchen Ã„nderungen dann den Ãœberblick über eventuell auftretende Probleme behalten zu können.