Ich habe am Wochenende ein wenig mit Pelican herumgespielt, um festzustellen, ob dieser Generator für statische Seiten als Nachfolger für RubyFrontier und dieses Blog Kritzelheft taugt. Denn gegenüber den anderen Alternativen wie Hugo, Jekyll und Gatsby, die ebenfalls in meinen Überlegungen eine Rolle spielen, hat das Teil zwei Vorteile:
Es ist in Python geschrieben und einfach in Python zu erweitern. Und Python ist nun mal die Programmiersprache, in der ich zu Haue bin. Mit meinen Ausflügen nach Ruby (wegen Shoes, RubyFrontier und Jekyll) und R (wegen RMarkdown) bin ich nicht wirklich glücklich geworden.
Es ist (neben RubyFrontier) vermutlich der einzige Generator für statische Seiten, der nicht in jedem Fall alle Seiten herausrendern will, sondern der auch die Möglichkeit bietet, nur einzelne Seiten oder Verzeichnisse herauszuschreiben. Zumindest habe ich diese Funktion bei den anderen Alternativen noch nicht entdeckt.
Ein weiterer Vorteil für mich ist, daß Pelican neben ReStructured Text und AsciiDoc natürlich auch Markdown als Eingabesprache unterstützt, und zwar Python Markdown samt seinen Extensions. Das ist deswegen ein Vorteil, weil ich damit schon durch MkDocs vertraut bin und ich dann meine Markdown-Texte Eins-zu-Eins vom Schockwellenreiter in MkDocs-Sites wie diese zu Processing.py übertragen kann.
Die Template-Engine hinter Pelican ist Jinja, also auch nicht gerade etwas, wovor man Angst haben müßte.
Der eigentliche Clou ist aber, daß man Pelican mit ein wenig Python-Code auch andere Eingabeformate unterjubeln kann. Daniel Rodriguez hat zum Beispiel ein Plugin geschrieben, damit Pelican als Eingabeformat auch IPython- respektive Jupyter-Notebooks akzeptiert und herausrendert. Es ist das Ergebnis früherer Codeversuche. Das Resultat kann dann so aussehen, also ziemlich gut und das Plugin gibt es hier auf GitHub.
Aber auch andere haben mit Pelican und Jupyter-Notebooks experimentiert:
Damit wäre die Möglichkeit geschaffen, mit Pelican so etwas wie computerisierte Essays (Computational Essays) zu schreiben. Auf Stephen Wolframs großartigen Aufsatz »What Is a Computational Essay?« und Tony Hirts Follow-Up »Programming, meh … Let’s Teach How to Write Computational Essays Instead« hatte ich ja im letzten November schon einmal hingewiesen. Ich selber hatte bisher erfolglos versucht, RubyFrontier Jupyter-Notebooks unterzujubeln (meine Ruby-Skills hatten dazu einfach nicht ausgereicht), aber da ich in Zukunft stärker mit Python arbeiten und über Python schreiben will, halte ich diese Möglichkeit für ziemlich genial. Ich werde das in der nächsten Zeit ausgiebig testen.
Mit RMarkdown soll Pelican übrigens auch spielen können, zumindest wenn man diesem Blogbeitrag von Michael Toth glaubt: »How to Write Pelican Blog Posts using RMarkdown & Knitr«.
Zum Schluß noch ein paar Tutorials:
Außerdem liefern die (Pelican-) Seiten von Walter Spiegel eine Menge von Informationen (nicht nur) zu Pelican.
Und hier die Bezugsquellen und die Dokumentation:
War sonst noch was? Ach ja, zu Wolframs oben erwähnten Aufsatz gibt es ein weiteres Follow Up von Andrew Gelman: »Wolfram Markdown, also called Computational Essay«, ganz frisch, vom 9. Juni dieses Jahres. Ich bin also nicht der Einzige, der sich mit solchen Überlegungen herumschlägt.
3 (Email-) Kommentare
Ich habe bislang mit hugo und jekyll herumgespielt; pelican ist mir aus denselben Gründen (Python) eigentlich auch am liebsten. Mir sind zwei Dinge aufgefallen, die ich noch lösen muss: Zum einen habe ich schon jetzt zwischen hugo und jekyll gemerkt, daß die Markdown-Syntax, Metadatenfelder, Naming der Posts, … subtil verschieden sind. Das ist kein großes Problem, so lang ich kleine Mengen an Einträgen dort drin. Wie das für größere Sites wird, weiß ich noch nicht - damit hänge ich aber wieder an einem speziellen Tool. Zum Zweiten habe ich gelegentliche Use Cases, in dem ich auch Content über Mobilgeräte posten möchte. Das funktioniert bei wordpress mit wordpress-App mehr schlecht als recht; bei einem Workflow mit statischen Pages und Generator ist es noch schwerer bis unmöglich. Vielleicht bleibt für solche Dinge dann doch ein Kanal wie Twitter oder Mastodon.
– Kristian R. (Kommentieren) (#)
Punkt 2) ist nicht unwesentlich. Ich habe in meiner Hugo-Installation noch keinen Weg gefunden, nur bestimmte Dateien neu herauszuschreiben. Das hat aber sicher auch damit zu tun, dass ich meinen Hugo auf Sicht fahre, d.h. immer erst dann in die Dokumentation gucke, wenn es gar nicht anders geht. Dazu kommt, dass dank der Schlagwortwolke, die auf jeder Seite ist, beim Hinzufügen eines neuen Schlagwortes ohnehin alle Seiten, auch die ältesten, neu geschrieben werden müssen.
Hugo gilt ja als besonders schnell, aber schon jetzt, zwei Wochen nach dem Neustart, braucht meine Windowskiste zwischen 0,9 und 2 sec. für das Herausschreiben aller Seiten incl. der Übersichtsseiten, Schlagwortseiten etc. (ist nicht wahnsinnig lang, aber doch bemerkbar).
Ich werde weiterbasteln.
– Konstantin K. (Kommentieren) (#)
Danke für die kreativen Vorschläge. Zwar wird es noch einige Zeit dauern, bis mein PythonLOnliner Seiten rendern kann, aber da ich gestern Markdown implementiert habe, kann ich auch gleich Python-Markdown + Extensiones, AsciiDoc und ResStructured Text mit aufnehmen. Das müsste dann für den Anfang reichen um gut mit dem Onliner arbeiten zu können. Mal nebenbei ist dein Blog hier ein Hort voll guter Ideen, von denen ich mir einige stibitzen möchte. :)
– Robert T. (Kommentieren) (#)
Über …
Der Schockwellenreiter ist seit dem 24. April 2000 das Weblog digitale Kritzelheft von Jörg Kantel (Neuköllner, EDV-Leiter, Autor, Netzaktivist und Hundesportler — Reihenfolge rein zufällig). Hier steht, was mir gefällt. Wem es nicht gefällt, der braucht ja nicht mitzulesen. Wer aber mitliest, ist herzlich willkommen und eingeladen, mitzudiskutieren!
Alle eigenen Inhalte des Schockwellenreiters stehen unter einer Creative-Commons-Lizenz, jedoch können fremde Inhalte (speziell Videos, Photos und sonstige Bilder) unter einer anderen Lizenz stehen.
Der Besuch dieser Webseite wird aktuell von der Piwik Webanalyse erfaßt. Hier können Sie der Erfassung widersprechen.
Diese Seite verwendet keine Cookies. Warum auch? Was allerdings die iframes
von Amazon, YouTube und Co. machen, entzieht sich meiner Kenntnis.
Werbung