Erfahrungsbericht: Pylons und Mako

[Leonidas]

Servus,

Ich habe heute endlich angefangen mir Pylons mal genauer anzusehen, d.h. genauer als nur die Webseite durchzulesen, sondern es auch tatsächlich einzusetzen.

Da dachte ich mir, dass ich passend zum Erfahrungsbericht: CherryPy und Cheetah einen analogen Erfahrungsbericht zu schreiben.

Also los:

Die Instalation

Die Installation von Pylons (0.9.6rc2) geht problemlos, benutzt setuptools und installiert unglaublich viele Eggs. Ein Problem war, dass das aktuelle stabile Release 0.9.5 ist und gewisse Änderungen in 0.9.6 eingeflossen sind, so dass ich nicht wusste, welche ich hätte nehmen sollen. Ich tippe aber, dass ich mit dem Release Candidate wohl die bessere Wahl getroffen habe. Dazu habe ich noch Elixir von easy_install installieren lassen, welches SQLAlchemy mitgezogen hat.

Informationen gibt es auf der Pylons-Seite in akzeptabler Quantität, empfehlenswert ist das Getting Started Dokument. SQLAlchemy hat auch viel Dokumentation, Elixir hingegen leider sehr wenig, d.h. fast keine brauchbare. Das Wiki ist in der Pylons-Seite ganz grauenhaft eingebunden und irritiert jedes mal, erinnert an TG - in Django sieht das wesentlich konsistenter aus und die Informationen sind leider teilweise auf die Versionen 0.9.5 und 0.9.6 verteilt. Aber das wird sich wohl bald nach dem Release von 0.9.6 ändern.

Wenn man außerhalb der Pylons Seite nach Informationen sucht, findet man noch zwei Screencasts. Der erste ist totale Zeitverschwendung, da wird nur gezeigt wie man Python installiert, Komodo Edit installiert und wie TortoiseSVN nutzt. Der andere ist etwas besser - man lernt dabei zwar nicht so viel, aber man bekommt zumindest einen groben Überblick über Pylons. Das Getting Started Dokument ist danach eine brauchbare Lektüre. Außerdem findet man noch einiges an CherryPy-Bashing (unprofessionelle Entwicklungsmethode, Bugs), aber ob das auch CP 3 betrifft weiß ich nicht. Dann findet man auch noch ein paar Notizen warum Mako besser als Cheetah ist (besseres Caching, mehr Features).

Was ich bisher von Routes gesehen habe wirft mich nicht aus den Schuhen, denn ich finde den Django-Delegator mit dessen Regular Expressions ziemlich brauchbar. Mal sehen ob Routes irgendeinen Interessanten Mehrwert bietet oder ob ich mir nicht noch selector ansehe.

Ich wollte eigentlich auch noch tesla einsetzen (um Elixir hübsch in Paste einzubinden), aber das zieht noch vielmehr Eggs mit und einige von den Projekten sind inzwischen unmaintained. Mal sehen wie sich das entwickelt.

Von der Qualität von Mako bin ich auch noch nicht ganz überzeugt, d.h. ich bin nicht sicher ob es mir gefällt, Python-Code ins Template zu tun. Auch das mysteriöse ``c``-Objekt finde ich eher seltsam. Da scheint mir die Context-Behandlung in Django expliziter und klarer zu sein. Im 2. Screencast sieht man, dass man in Mako auch Templatevererbung hat und dort über Python-Code so etwas wie Blöcke hinbekommt.

Die Datenbank, Teil 1 + Support

Pylons setzt keinerlei ORM vorraus, Pylons ist es völlig egal woher die Daten kommen. Das geht sogar so weit, dass Pylons schlcihtweg kein ORM mitbringt. Die meisten nutzen jedoch das bekannte SQLAlchemy ein. Da SQLAlchemy im vergleich mit ORMs wie SQLObject oder Storm etwas "eigen" ist, nutzen einige auch noch den Wrapper Elixir der es ermöglicht, die Datenbankmodelle etwas deklarativer zu definieren (ist übrigens aus TurboENtity und ActiveMapper hervorgegangen). So wie SQLAlchemy eine sehr umfassende und brauchbare und, ja, auch bitter nötige Dokumentation hat, so finde ich die Dokumentation zu Elixir etwas spärlich. Viele Objekte kommen aus SQLAlchemy, also muss man immer zwei Dokumentationen konsultieren.

Letztendlich habe ich mich aber gegen Elixir entschieden, denn so sehr interessierte mich das dann doch nicht und dachte mir, dass ich erstmal mich in SQLAlchemy einarbeite. Am glecihen Tag wie ich das gemacht habe, wurde SQLAlchemy 0.4.0beta1 fertig und mir wurde empfohlen, gleich das einzusetzen. Nun warte ich auf ein 0.4 Release der Hilfsbibliothek SAContext - gut dass ich diese Woche nicht da bin, vielleicht passiert ja etwas in der Woche.

Bin auch schon in meine ersten Probleme reingeraten, als ich das Dokument SQLAlchemy for people in a hurry durchgearbeitet habe. Diese wurden mithilfe der Leute aus #pylons gelöst, der Pylons-Entwickler benbangert (aka Ben Bangert) war selbst anwesend und hat mir einige Tipps gegeben. Ebenso hat mir zzzeek (aka Mike Bayer), der SQLAlchemy entwickelt geholfen einen Fehler in ebendiesem Dokument aufzudecken und mir einige Fragen bezüglich der Typen erklärt.

Der Support auf #django ist dank Leuten wie Magus- gut, aber das die Entwicker dort online sind ist selten. Daher finde ich es überaus positiv, dass die Entwickler von Pylons und SQLAlchemy so leicht erreichbar sind.

Bisher habe ich es leider noch nicht geschafft meine Daten aus der alten Datenbank in eine SQLAlchemy Datenbank zu migrieren, was aber teilweise auch daran liegt, dass ich unglaublich viel drumrum erst noch erkunden musste.

Edit: Zweiten Abschnitt geschrieben.

[veers]

Mako habe ich auch schon verwendet. Bin mir jedoch auch noch nicht sicher ob mir der Ansatz besser/weniger gut gefallen soll als der von jinja/django. Grundsätzlich bin ich jedoch der Meinung das auch mächtige Templates nichts falsches sind und nur ein bisschen Eigenverantwortung fordern.

Zu Routes, was mir da gefallen hat ist wie einfach es ist links zu erzeugen und diese zu verändern. Andererseits kam es mir sehr "klobig" vor. Aber das Link erzeugen scheinen sie bei django auch in den Griff bekommen zu haben.

Und zu Pylons:
Komponenten wieder verwenden mag ja toll sein. Bei Pylons halte ich es jedoch für absolut übertrieben. Die ganzen dependencies sind der Wahnsinn. Da verwende ich lieber WSGI und baue mir selber etwas zusammen.

Derzeit verwende ich jedoch immer noch meist CGI. Django hat auf mich ganz nett gewirkt. Abgesehen davon dass es einfach sehr gross und so ein richtiges Framework ist. "Kann man das irgend wie brauchen? Ja? Gut dann fügen wir diese Funktion auch noch hinzu".

[Leonidas]

Mako habe ich auch schon verwendet. Bin mir jedoch auch noch nicht sicher ob mir der Ansatz besser/weniger gut gefallen soll als der von jinja/django. Grundsätzlich bin ich jedoch der Meinung das auch mächtige Templates nichts falsches sind und nur ein bisschen Eigenverantwortung fordern.

Ja, es gibt dazu zwei Meinungen, die ich aber beide verstehen kann. Eigenverantwortung ist eben so eine Sache, wenn man selbst aufpasst dass man nicht zu viel Logik in die Templates reinschreibt ist das ja ok, aber spätestens wenn man irgendwelche Leute ranlässt (ranlassen muss) die nichts von sauberem Code halten ist so ein Template-System nicht optimal. Klar, auch das von Django kann man aushebeln.
Ich habe zum Beispiel mal 2 Tags gesehen die jeweils <!-- und --> in den Code eingefügt haben, um bestimmte Elemente ein und auszublenden. Da ist mir erstmal gar nichts mehr eingefallen und ich müsste jetzt überlegen ob es traurig oder komisch war - vermutlich grotesk.

Zu Routes, was mir da gefallen hat ist wie einfach es ist links zu erzeugen und diese zu verändern. Andererseits kam es mir sehr "klobig" vor. Aber das Link erzeugen scheinen sie bei django auch in den Griff bekommen zu haben.

Also wie das bei Django funktioniert, habe ich immer noch nicht herausgefunden, die Dokumentation war irgendwie kaum hilfreich. Im Pylons Screencast habe ich hingegen diese aus Rails portierten WebHelper gesehen und bei dem Code den der da zusammegekloppt hat, kam mir irgendwie das Grausen.
Aber vielleicht bin ich auch zu sehr voreingenommen und möchte alles selbst regeln - ich werde wohl sehen müssen, ob die Automatismen brauchbar sind.

Naja, ich habe ja noch im Zweifelsfall Y0Gis Upraise - hat zwar keine Dokumentation, aber ich habe den Entwickler in meinem Roster und das ist schon mal was

Und zu Pylons:
Komponenten wieder verwenden mag ja toll sein. Bei Pylons halte ich es jedoch für absolut übertrieben. Die ganzen dependencies sind der Wahnsinn.

Ja, das Egg für decorators fand ich auch schon recht übertrieben, aber vielleicht ist das ja auch unglaublich brauchbar. Was ich schlimm fand, war eine Phase von TG, in der es riesige Mengen Eggs mitgezogen hat. Da war TG 0.7 damals richtig moderat.

Derzeit verwende ich jedoch immer noch meist CGI. Django hat auf mich ganz nett gewirkt. Abgesehen davon dass es einfach sehr gross und so ein richtiges Framework ist. "Kann man das irgend wie brauchen? Ja? Gut dann fügen wir diese Funktion auch noch hinzu".

Naja, an Django stößt mich im Moment hauptsächlich das ORM ab, mit dem ich dauernd auf Kriegsfuß stehe: "Simple things simple, complicated things buggy or impossible". Ansonsten finde ich das Framework ziemlich brauchbar, bis auf einige kleine Details (Context vs. RequestContext) und bedauerlicherweise auch den Deadlock.

Was mich momentan stört, ist der Mangel an Dokumentation zu Elixir, ich vermute dass das was in der Dokumentation dazu fehlt, zu SQLAlchemy gehört - so macht Lesen definitiv keinen Spaß.

Im nächsten Teil wird es wohl um die Datenbankanbindung gehen, denn das wäre mein nächster Schritt in meinen Testprogramm.

[veers]

Mako habe ich auch schon verwendet. Bin mir jedoch auch noch nicht sicher ob mir der Ansatz besser/weniger gut gefallen soll als der von jinja/django. Grundsätzlich bin ich jedoch der Meinung das auch mächtige Templates nichts falsches sind und nur ein bisschen Eigenverantwortung fordern.

Ja, es gibt dazu zwei Meinungen, die ich aber beide verstehen kann. Eigenverantwortung ist eben so eine Sache, wenn man selbst aufpasst dass man nicht zu viel Logik in die Templates reinschreibt ist das ja ok, aber spätestens wenn man irgendwelche Leute ranlässt (ranlassen muss) die nichts von sauberem Code halten ist so ein Template-System nicht optimal.

Ja, ich denke aber das für solche Leute Python und auch C ganz einfach die falschen Programmiersprachen. Beide sind sehr mächtig und... "With great power comes great responsibility". Ist wohl auch eine erklärung wieso Java in der Geschäftswelt so beliebt ist (und wieso Reflection in Java so kompliziert ist, die die es können werden schon wissen was sie tun *g*).

Also wie das bei Django funktioniert, habe ich immer noch nicht herausgefunden, die Dokumentation war irgendwie kaum hilfreich.

Wenn ich das richtig verstanden habe gibst du einen Urls Namen und kannst dann mit dem Templatetag url darauf verweisen. Aber ich bin mir nicht so sicher ob das eine gute Idee ist Regex "rückwärts" laufen zu lassen. Mir wäre ein printf/scanf artiges Format viel lieber.

[Leonidas]

Update: Ich habe einen weiteren Absatz hinzugefügt.

Weitere Diskussionen sind durchaus erwünscht, auch wenn jemand andere Beobachtungen gemacht hat und mir sagen will, dass er täglich einen Stunde mit Adrian oder Jacob oder auch DHH chattet