Das deutsche Python-Forum

Ich bin derzeit mal wieder einige (zwei) kleine Webanwendungen in Python am schreiben. Das eine ist ein Script um meine Musik Sammlung darzustellen, das andere ein kleine Bookmark Verwaltung. Beide als CGI. Das scheint mir aber doch sehr altertümlich und umständlich.
Ich habe auch eine kleine Seite mit Django gebastelt. Das hat mir Grundsätzlich sehr gut gefallen, aber wenn ich sehe wie lange ich hatte bis das ganze auf einem Produktiv System halbwegs funktionierte dann muss ich sagen dass ich das keinem Endbenutzer zumuten kann. Es scheint mir zumindest als wäre Django mehr auf einzelne Websites als auf Anwendundungen für "Endbenutzer". Dieser eindruck wird unter anderem verstärkt durch das Fehlen eines UrlHelpers wie ihn Rails hat.

Eine CGI Anwendung kann entpacken und mit etwas Glück funktioniert das ganze dann auch schon. Für PHP gilt das selbe.

Ich suche ein leichtes Webframework, welches mir nicht in die Quere kommt, das Programmieren erleichtert und einfach zu verteilen ist. Was für alternativen gibt es noch? Pylons? Gibt es Anwendungen welche mit Django/WSGI eine grössere Verbreitung gefunden haben? WSGI scheint mir für den Endbenutzer auch noch umständlich zu sein. Würde sich aber vermutlich mit einem entsprechenden Meta Applikation (paste?) beseitigen lassen. Aber vielleicht täusche ich mich da auch.

Was ist für Dich ein Endbenutzer?

Karrigell ist ganz nett:

http://karrigell.sourceforge.net/

veers hat geschrieben:Ich suche ein leichtes Webframework

Hallo veers!

Ich schreibe gerade an einem ersten Erfahrungsbericht zu CherryPy und Cheetah. (Ich will mich weiterbilden...) Vielleicht ist das ja etwas für dich. Morgen oder übermorgen sollte ich damit fertig sein.

http://gelb.bcom.at/trac/misc/wiki/Tuto ... yPyCheetah

CherryPy lässt sich von der Kommandozeile aus starten oder mit mod_python oder WSGI in den Apachen integrieren.

Wie das funktioniert, werde ich wahrscheinlich erst in ein paar Tagen zu berichten wissen. CherryPy sowie Cheetah sind reine Python-Pakete und können (wenn man möchte), ohne Installation, in das eigene Programm integriert werden.

mfg
Gerold

BlackJack hat geschrieben:Karrigell ist ganz nett:

1.) Nicht WSGI kompatibel
2.) hast du dir den Quellcode mal angesehen?

WSGI scheint mir für den Endbenutzer auch noch umständlich zu sein. Würde sich aber vermutlich mit einem entsprechenden Meta Applikation (paste?) beseitigen lassen. Aber vielleicht täusche ich mich da auch.

Es gibt einige wrapper rund um WSGI. Große wie Pylons, Django, CherryPy etc. Und dann kleine und flexible Lösungen wie paste und neuerdings auch werkzeug, aber da ich da mitentwickle bin ich da befangen.

BlackJack hat geschrieben:Was ist für Dich ein Endbenutzer?

Gute Frage

Ein nicht Python Entwickler. Wenns gut kommt ein *nix Benutzer, im schlimmsten Fall meine Freundin

Zu Cherrypy(+Cheetah) habe ich mir auch schon angesehen, hat mir Anfangs auch Recht gut gefallen. Ich weis garnicht mehr genau warum ich damit aufgehört habe. Ich glaube es wirkte mir zu Unsauber oder kam mir in den weg. Werds aber sicher nochmals ansehen.

blackbird,
werkzeug sieht nett aus, löst das Distributions Problem aber auch nicht?
Werde aber auf jeden Fall auch einmal einen Blick darauf werfen.

Zu Cherrypy(+Cheetah) habe ich mir auch schon angesehen, hat mir Anfangs auch Recht gut gefallen. Ich weis garnicht mehr genau warum ich damit aufgehört habe. Ich glaube es wirkte mir zu Unsauber oder kam mir in den weg. Werds aber sicher nochmals ansehen.

Kann es nur empfehlen. Ich habe lange Zeit nach einer schönen Lösung gesucht. Die Frameworks waren mir zu groß (wirklich! mind. 50% habe/werde ich bei meinen Projekten nie brauchen), andere Sachen wie Paste irgentwie unangenehm. Eine zeitlang habe ich mich in Colubrid verfangen. Habe es angefangen schön zu finden, bis ich mir mal genauer CherryPy angesehen habe.
Zwischenzeitlich Werkzeug. Was (mein empfinden) irgentwie einen komplett anderen Weg als CherryPy oder Colubrid geht und für mich irgentwie "zu nah" am Kern sitzt. (was durchaus seine Vorteile hat)
Hier hat man z.B. das Problem, das man sich erstmal eine komplette Grundstruktur schreiben muss, bevor man "richtig" loslegen kann.
(mal von den Starttemplates abgesehen)
Da fand ich Colubrid schöner

blackbird,
werkzeug sieht nett aus, löst das Distributions Problem aber auch nicht?
Werde aber auf jeden Fall auch einmal einen Blick darauf werfen.

Was heißt Distributionsproblem?
WSGI-Anwendungen können (rein theoretisch) via CGI, mod_python, SCGI, FastCGI etc ausgeführt werden. Das ist jedenfalls besser, als direkt für einen dieser Handler zu entwickeln.
Jedoch ist das mitliefern von allumfassenden Konfigurationen dadurch schwerer/unmöglich, was für den Benutzer durchaus tiefere Eingriffe in die Konfigurationen des Servers erfordert.
Karrigel, hat nur eine Möglichkeit "Verteilt zu werden". Via (schlagt mich, wenn falsch) mod_rewrite oder halt den Apache auf den integrierten Server umleiten, glaub mod_proxy hieß das. (geht natürlich auch mit anderen HTTP-Servern)

MfG EnTeQuAk

[offtopic]
@blackbird: Was war eigentlich der Grund für Werkzeug und gegen Colubrid?

EnTeQuAk hat geschrieben: Was heißt Distributionsproblem?
WSGI-Anwendungen können (rein theoretisch) via CGI, mod_python, SCGI, FastCGI etc ausgeführt werden. Das ist jedenfalls besser, als direkt für einen dieser Handler zu entwickeln.
Jedoch ist das mitliefern von allumfassenden Konfigurationen dadurch schwerer/unmöglich, was für den Benutzer durchaus tiefere Eingriffe in die Konfigurationen des Servers erfordert.

Das ist so ungefähr das Problem. Ein grosser Teil der Nutzer können/wollen ihre Webserver Konfiguration nicht anpassen. Ich glaube das ist auch einer der Gründe für die Popularität von PHP. Da reicht normalerweise hoch laden und Setup durchklicken/Config anpassen. Mir ist bewusst das es auch da bei grösseren Anwendungen wie Typo3 nich ganz so einfach ist. Aber wer ein Typo3 aufsetzt wird schon wissen was er tut. Das kann man vom Benuter einer Lesezeichen Verwaltung oder eines Musik Indexes nicht sagen

Da sollte sich das ganze in max. 10 Minuten installieren lassen.

EnTeQuAk hat geschrieben:@blackbird: Was war eigentlich der Grund für Werkzeug und gegen Colubrid?

Weil Colubrid ein paar Design Fehler hat und man die nicht fixen kann ohne bestehende Anwendungen kaputt zu machen. Daher werkzeug als unabhängiger Colubrid Nachfolger.

@veers: Distributionsproblem hast du mit WSGI nicht. Mach einfach ein paar fertige foo.cgi, foo_modpy.py, foo.fcgi, die sind pro Datei ~3 Zeilen lang. Und dokumentier zusätzlich noch den WSGI Einspringspunkt für Leute, die komplexere Serversettings haben.

Beispiel für eine foo.fcgi:

Code: Alles auswählen

#!/usr/bin/python
from flup.server.fastcgi import WSGIServer
from myapplication import make_app
WSGIServer(make_app()).run()

Die geht auch für CGI, mod_python gibts auch Handler für. Einfach ein wenig googlen. Alles in allem kein Problem.

blackbird hat geschrieben:
BlackJack hat geschrieben:Karrigell ist ganz nett:
1.) Nicht WSGI kompatibel

veers hat geschrieben:Pylons?

Pylons ist vom Umfang ähnlich groß wie Django, zumindest wenn du es zu etwas brauchbarem nutzen willst. Dann brauchst du SQLAlchemy + Templatesystem + Rattenschwanz an Dependencies.

veers hat geschrieben:Ein grosser Teil der Nutzer können/wollen ihre Webserver Konfiguration nicht anpassen. Ich glaube das ist auch einer der Gründe für die Popularität von PHP. Da reicht normalerweise hoch laden und Setup durchklicken/Config anpassen.

Hallo veers!

@veers:
Ja, das ist der Grund, weshalb Python in der Web-Programmierung nie den Stellenwert von PHP erreichen kann. Es ist zu kompliziert, eine einfache, dynamische Seite zu erstellen.

@wsgi_leute:

Dann gibt es hier im Forum noch Leute, die dir einfach nur zu WSGI raten. Aber WSGI ist nur die Technik dahinter und ist für die einfache Programmierung einer kleinen (oder auch großen) Website zu tief am Eingemachten. (ich habe es ausprobiert -- es war schrecklich)

Mir würde es besser gefallen, wenn ein Framework (begründet) empfohlen wird und keine Technik. Mit der "Technik" WSGI können oder wollen viele, inklusive mir, nichts oder nur wenig zu tun haben. Wenn ein Framework WSGI kann --> Gut. Aber wenn das Framework genau das ist, was ich als Programmierer suche, es aber nicht WSGI kann, dann ist es mir auch egal. Dann kann ich es immer noch mit mod_rewrite hinter einen Apachen klemmen.

Es ist richtig, dass WSGI als technische Basis für die Webprogrammierung mit Python etabliert werden muss. Aber das betrifft die Frameworkprogrammierer und nicht die Programmierer, die einfach nur eine Webanwendung schreiben möchten.

Achtung Gedankenfetzen:
WSGI wird hier überall empfohlen! Also muss ich es ausprobieren. Na super!!! Dokumentation: Hier ein kleiner Fetzen, dort eine kleine Andeutung. Nur einfache HalloWelt-Beispielprogramme, die nicht erklären, wie man eine Struktur in die Anwendung bringen könnte. Wie liefert man statische Objekte aus? Gar nicht -- lass das vom Webserver erledigen. Na super! Das sind Meldungen!!!

...ich mag jetzt nicht mehr weiterschreiben.

lg
Gerold

gerold hat geschrieben:Morgen oder übermorgen sollte ich damit fertig sein. http://gelb.bcom.at/trac/misc/wiki/Tuto ... yPyCheetah

Es ist jetzt schon mal so weit, dass das Geschriebene einen Sinn ergibt. Es fehlt zwar noch ein Beispiel mit mehreren Ordnern und Dateien und die Integration in den Apachen, aber ich denke, als kleine Einführung könnte der Erfahrungsbericht schon mal durchgehen.

http://gelb.bcom.at/trac/misc/wiki/Tuto ... yPyCheetah

Viel Spaß beim Ausprobieren.

lg
Gerold

gerold zum Thema WSGI full ACK von meiner Seite. Exakt so empfinde ich das auch.

veers hat geschrieben:Ich habe auch eine kleine Seite mit Django gebastelt. Das hat mir Grundsätzlich sehr gut gefallen, aber wenn ich sehe wie lange ich hatte bis das ganze auf einem Produktiv System halbwegs funktionierte dann muss ich sagen dass ich das keinem Endbenutzer zumuten kann. Es scheint mir zumindest als wäre Django mehr auf einzelne Websites als auf Anwendundungen für "Endbenutzer". Dieser eindruck wird unter anderem verstärkt durch das Fehlen eines UrlHelpers wie ihn Rails hat.

Eine CGI Anwendung kann entpacken und mit etwas Glück funktioniert das ganze dann auch schon. Für PHP gilt das selbe.

Ich versuche mit PyLucid ein Endbenutzer freundliches CMS zu entwickeln. Dabei benutzte ich django. Es soll möglichst einfach auf Shared-WebHosting Servern "installiert" werden können (ohne shell Zugang). Dazu ist django erstmal nicht ausgelegt. Aber mit einigen Zusätzlichen Code ist es dennoch möglich.
Damit es möglichst einfach wird, liefere ich z.B. eine lokale Django Installation gleich mit. Somit kann man das ganze einfach mit dem FTP Client hochladen und loslegen...

Das PHP Apps generell einfach zu installieren sind, liegt aber auch daran, das die Shared-Web-Server möglich offen dafür konfiguriert sind. Sicher ist das aber ehr weniger...

Was sind den die UrlHelpers von Rails? Was kann man damit machen?

EDIT:

gerold hat geschrieben:CherryPy lässt sich von der Kommandozeile aus starten oder mit mod_python oder WSGI in den Apachen integrieren.

Auch braucht man für CherryPy auch einen shell Zugang, ja? Wenn das schon Voraussetzung ist, eignet sich das wohl weniger für Endanwender... Genauso ist es doch auch mit Karrigel, oder nicht? Einfach per FTP hochladen und benutzten ist da auch nicht drin... Oder irre ich mich da?

Ich persönlich habe WSGI ob der zahlreichen Deployment-Möglichkeiten (von *CGI über mod_python bis Standalone/"geproxied") und des einheitlichen Interfaces zu schätzen gelernt.

gerolds Erfahrung, WSGI sei schwer zu verwenden, kann ich nicht nachvollziehen. Allerdings habe ich auch nicht direkt die WSGI-Schnittstelle angesprochen - das sollte man für die Anwendungsentwicklung IMHO auch nicht tun, sondern eine WSGI-Abstraktion verwenden, wie sie Paste und Werkzeug bieten. Da hat man dann Klassen für Request, Response und äh... das war's ja hauptsächlich schon.

Was darüber hinaus geht, ist Teil des Frameworks. Man kann sich auf die größeren üblichen Verdächtigen (wie z.B. Pylons) stützen oder da selbst etwas für die eigene Anwendung basteln. Ich selbst habe ja meinen dünnen Layer zwischen Applikation und Paste in Upraise ausgelagert (neue Version mit wichtigen Änderungen kommt demnächst) und bin sehr zufrieden (außer, dass ich mich von Paste lösen können und Werkzeug unterstützen bzw. ganz darauf umsatteln möchte).

Wenn Applikationen an nicht-Entwickler weitergegeben werden sollen, ist Paste Deploy eine große Hilfe. Dessen Zweck ist es, dem außenstehenden Administrator das Aufsetzen, Konfigurieren und Kombinieren von WSGI-Applikationen sowie von ihm gewünschten Middlewares über .ini-Konfigurationsdateien zu ermöglichen.

Wenn man eine Applikation bereitstellt, die als Python-Egg über den Cheeseshop verfügbar ist und ihre Abhängigkeiten sauber angibt, reicht in der Regel ein einfacher easy_install-Aufruf und der benötigte Haufen Code wandert auf's System. Ein paar Änderungen an Config- oder den o.g. Paste-.ini-Dateien sowie drei Zeilen in der Apache-/*-Konfiguration dürften keinen brauchbaren Sysadmin überfordern. Und der gemeine Hobby-Nutzer kriegt das auch locker hin, wenn die Doku stimmt.

Dann gibt es hier im Forum noch Leute, die dir einfach nur zu WSGI raten. Aber WSGI ist nur die Technik dahinter und ist für die einfache Programmierung einer kleinen (oder auch großen) Website zu tief am Eingemachten. (ich habe es ausprobiert -- es war schrecklich)

Die, die es allerdings (richtig) machen, empfehlen hier kein einfaches WSGI sondern entsprechende WSGI-Handler oder Frameworks.

Und sich über Vor und Nachteile von WSGI(-Anwendungen) aufzuregen, was die Einsatzmöglichkeit angeht, mit Karrigell im Rücken ist auch nicht wirklich sinnvoll. Denn Karrigell unterstützt es nicht, braucht (meines Wissens nach) immer den eigenen Webserver, was für Shared-Hosting schonmal absolut gar nicht (oder nur in extremfällen) möglich ist.

Das PHP Apps generell einfach zu installieren sind, liegt aber auch daran, das die Shared-Web-Server möglich offen dafür konfiguriert sind. Sicher ist das aber ehr weniger...

Genau, das ist auch mein Gedanke. Wie wird PHP ausgeführt? Entweder über mod_php bei Apache oda einfach über CGI. CGI ist bei Python ebenso die "einfachste" Anwendungsschicht. Zumindest ohne groß mit anderen Abstraktionsschichten (hieß das so?) wie mod_python etc. rumzumachen.

Und mal ehrlich: Mal genauer drüber nachgedacht, ist Python im Web zu 99,9% nicht schwerer/komplizierter, als PHP. Vergleichen mit Ruby oder Java braucht man das glaube ich nicht. (bei ruby weiß ich nicht, ob das auch so einfach über CGI geht)

Ja, das ist der Grund, weshalb Python in der Web-Programmierung nie den Stellenwert von PHP erreichen kann. Es ist zu kompliziert, eine einfache, dynamische Seite zu erstellen.

PHP ist einfach so einfach, weils jeder Shared Hoster anbietet. Als Hoster braucht man "nur" entsprechende (Apache) Module (und die meißten verwenden Apache) zu installieren, gut abzusichern und dann sollte die Konfiguration eigentlich komplett via .htaccess möglich sein. Und via .htaccess ist einiges möglich.

Also --> .htaccess + Konfiguration + entsprechender Handler für FastCGI, mod_python & co = Voll einsatzfähige Anwendung ohne Einschränkung.

Und rein von der Programmiererseite, willst du nicht sagen, das es so viel Schwerer ist eine Dynamische Internetapplikation zu erstellen, oder?

[offtopic]

Weil Colubrid ein paar Design Fehler hat und man die nicht fixen kann ohne bestehende Anwendungen kaputt zu machen. Daher werkzeug als unabhängiger Colubrid Nachfolger.

Die währen? (interessiert mich einfach

)
Nichts desto trotz habe ich mir Werkzeug die letzten Tage mal näher angeschaut und habe auch schon erste lauffähige mini Anwendungen hinbekommen. Außer, das das URL-Mapping irgentwie anders ist (ungewohnt für mich), is es ganz schick geworden. Nur einige Beispielanwendungen sind kaputt, werde mir nochmal alles anschauen und dir mal bescheid sagen, wenn ich mal irgentwann wieder Zeit habe ins IRC zu kommen.

Da reicht normalerweise hoch laden und Setup durchklicken/Config anpassen

Sag das nicht...

Entweder mache ich immer etwas falsch oder ich kenne Sehr viele Punkte, wo PHP Anwendungen nicht nur einfach hochladen und klick und fertig sind.
Viele (sogar sehr viele) benötigen auch noch die Anpassung von Anwendungsrechten. Hier fängts schon an *g*

Alles in Allem ist es nur eine Anschauung. Genauer betrachtet liegt alles vom Schwierigkeitsgrad nah bei einander.

MfG EnTeQuAk

EnTeQuAk hat geschrieben:(bei ruby weiß ich nicht, ob das auch so einfach über CGI geht)

Ja. Seit Rails macht das aber keiner. Rails hat schon Hoster-Support in Form von FastCGI oder Mongrel.

EnTeQuAk hat geschrieben:Außer, das das URL-Mapping irgentwie anders ist (ungewohnt für mich)

Das Mapping scheint sich an das von Routes anzulehnen. Routes ist ein Bekannter aus Pylons, und es hat sich einiges von Rails abgeschaut.

Ruby hat mit Rack jetzt ein WSGI ähnliches Interface bekommen.

Wenn ich nun aber kein eigenes Framework entwickeln will, wieso muss ich mich mit WSGI überhaupt beschäftigen? Und wieso ist das denn so wahnsinnig wahnsinnig wichtig, dass hier gleich der erhobene Zeigefinger mit Blitzen kommt, wenn jemand was anderes vorschlägt?

N317V hat geschrieben:Wenn ich nun aber kein eigenes Framework entwickeln will, wieso muss ich mich mit WSGI überhaupt beschäftigen? Und wieso ist das denn so wahnsinnig wahnsinnig wichtig, dass hier gleich der erhobene Zeigefinger mit Blitzen kommt, wenn jemand was anderes vorschlägt?

Schau dir den Blitz nochmal genauer an. Du sollst dich damit ja gar nicht beschäftigen. Sondern der Entwickler des Frameworks. Und der Karrigell Entwickler sträubt sich dagegen.

Das deutsche Python-Forum

Python Webframework

Python Webframework

Re: Python Webframework

Re: Python Webframework

Re: Python Webframework

Re: Python Webframework