Python im Web für PHP-Umsteiger

[_kosmos_]

Hallo,

ich habe bisher Webanwendungen mit PHP realisiert. Einer der Hauptvorteile war: Eine Applikation läuft meistens ohne großartige Anpassungen auf jedem beliebigen (Shared-)Webhost.

Ich möchte trotzdem auf Python umsteigen. Ich habe mich tagelang eingelesen und bisher Django, TurboGears und web.py probiert. Natürlich habe ich auch ein paar CGI-Scripts geschrieben.

Nun aber meine Fragen:

Wenn ich das richtig verstanden habe, sind mod_python und CGI-Anwendungen nur schwer portierbar, daher existiert die WSGI-Spezifikation. Als Konsequenz für den Entwickler baut man daher wohl Python-Web-Anwendungen eher innerhalb von Frameworks statt direkt auf mod_python oder *CGI aufzusetzen. Richtig?

Django und TurboGears sind schöne Frameworks, ehrlich. Jedoch kann man es fast vergessen, diese auf Shared-Webhosting-Umgebungen innerhalb von Apache aufzusetzen. Ohne Shell-Zugriff kann man das wohl gar nicht. (Von Zope mal ganz zu schweigen)

Django, TurboGears und andere sind mir aber ohnehin zu mächtig. Sie liefern einen HTTP-Server mit, den ich nicht brauche – ich will ja die Applikation auf dem Apache laufen lassen. Daher bin ich auf der Suche nach einem kleineren Framework. Dieses soll folgendes leisten:

• Kein Webserver mitgeliefert

• implizierter URL-Aufruf wie beispielsweise bei CodeIgniter(.com): Klasse foo mit Methode bar erstellen und http://example.com/foo/bar aufrufen (aber kein Muss)

• Möglichst einfache Integration in Apache-Umgebungen

• Einfache Möglichkeit, die Anwendung in verschiedenen Umgebungen (mod_python, cgi, fastCGI) unter Apache zu deployen

Vielleicht kann mir jemand helfen?


Danke
_kosmos_[/b]

[Leonidas]

Hallo _kosmos_, willkommen im Forum,

Als Konsequenz für den Entwickler baut man daher wohl Python-Web-Anwendungen eher innerhalb von Frameworks statt direkt auf mod_python oder *CGI aufzusetzen. Richtig?

Richtig.

Ohne Shell-Zugriff kann man das wohl gar nicht. (Von Zope mal ganz zu schweigen)

Du kannst Django mit CGI betreiben, FastCGI könnte gehen, solange der Hoster das unterstützt.

Django, TurboGears und andere sind mir aber ohnehin zu mächtig. Sie liefern einen HTTP-Server mit, den ich nicht brauche – ich will ja die Applikation auf dem Apache laufen lassen.

Djangos HTTP-Server ist nur als Development-Server gedacht. Im Produktivbetrieb setzt man onehin Lighttpd oder Apache ein.

Kein Webserver mitgeliefert

Ist das Vorhandensein dieses Features ein Kickout-Kriterium?

implizierter URL-Aufruf wie beispielsweise bei CodeIgniter(.com): Klasse foo mit Methode bar erstellen und http://example.com/foo/bar aufrufen (aber kein Muss)

Geht mit WSGI.

Möglichst einfache Integration in Apache-Umgebungen

Sollte mit WSGI gehen.

Einfache Möglichkeit, die Anwendung in verschiedenen Umgebungen (mod_python, cgi, fastCGI) unter Apache zu deployen

WSGI.

Vielleicht kann mir jemand helfen?

Ja, ein kleines WSGI-Framework. Du solltest dir mal Colubrid oder ein anderes WSGI-Framework ansehen.

[BlackJack]

CGI-Anwendungen lassen sich einfach portieren; CGI ist *der* webserver- und sprachübergreifende Standard. Ist halt nur nicht ganz so schnell wie Schnittstellen, die weniger portabel, dafür aber enger mit dem Webserver verbunden sind. Und man muss bei CGI alles selber schreiben, was in Webframeworks normalerweise schon enthalten ist, wie zum Beispiel Unterstützung für Sessions.

Und das Kriterium "soll keinen Webserver mitliefern" kannst Du vergessen, weil der im grossen und ganzen schon beim normalen Python dabei ist. Die paar zusätzlichen Zeilen Quelltext die dabei in einem Webframework dazukommen kannst Du vernachlässigen.

Webhoster mit guter Pythonunterstützung sind leider (noch?) spärlich gesäht. Für grosse Anwendungen ist ein selbstverwalteter Server besser geeignet.

[_kosmos_]

Vielen Dank für Deine Antwort, Leonidas!

Du kannst Django mit CGI betreiben, FastCGI könnte gehen, solange der Hoster das unterstützt.

Ja, geht auch. Ich habe es schon auf meinem Shared-Host mit einem FastCGI-Dispatcher installiert. Nichtsdestotrotz ist mit Django einfach zu "groß". Und das explizierte Konfigurieren der URL-Dispatchings nervt mich gewaltig.

Kein Webserver mitgeliefert

Ist das Vorhandensein dieses Features ein Kickout-Kriterium?

Nein, nicht wirklich. Dennoch wäre es sehr angenehm, ein Framework zu finden, das keinen Webserver ausliefert um Neueinsteiger, denen ich Python im Web etwas näher bringen möchte, sehr schön.

Ja, ein kleines WSGI-Framework. Du solltest dir mal Colubrid oder ein anderes WSGI-Framework ansehen.

[/quote]

Ja, darauf bin ich ja auch schon gekommen. Nur: Welches?
Ich habe mich jetzt mehere Tage mit Frameworks rumgeschlagen. web.py zum Beispiel produziert in der Download-Version Syntax-Fehler und in der SVN-Version funktioniert der WSGI-Kram nicht.

Ich suche wie gesagt ein Framework, das ein Einsteiger "mal eben" per FTP auf seinen Webhost schiebt, eine Datei anlegt, in der er seine Klassen und Funktionen definiert und das Ganze dann sofort ohne großartige Konfiguration lauffähig ist...
Vielleicht hat ja bereits jemand anderes derariges gesucht und befreit mich davon, alles auszuprobieren.


Vielen Dank!

[_kosmos_]

CGI-Anwendungen lassen sich einfach portieren; CGI ist *der* webserver- und sprachübergreifende Standard. Ist halt nur nicht ganz so schnell wie Schnittstellen, die weniger portabel, dafür aber enger mit dem Webserver verbunden sind. Und man muss bei CGI alles selber schreiben, was in Webframeworks normalerweise schon enthalten ist, wie zum Beispiel Unterstützung für Sessions.

Und das Kriterium "soll keinen Webserver mitliefern" kannst Du vergessen, weil der im grossen und ganzen schon beim normalen Python dabei ist. Die paar zusätzlichen Zeilen Quelltext die dabei in einem Webframework dazukommen kannst Du vernachlässigen.

Webhoster mit guter Pythonunterstützung sind leider (noch?) spärlich gesäht. Für grosse Anwendungen ist ein selbstverwalteter Server besser geeignet.

1. Natürlich kann ich CGI-Anwendungen portieren, schon klar. Nur ging es mir darum, dass ich ein Python-Programm (z.B. eine Blog-Software oder ein Gästebuch oder oder oder) fertig in der Schublade liegen habe, das dann auf unterschiedlichen Zielplatformen läuft: Apache mit CGI, Apache mit FastCGI oder Apache mit mod_python.

2. "gute Python-Unterstützung" ist genau der Punkt Sobald der Webserver CGI auch mit Python durch den Interpreter jagt, sollte eine Python-Applikation in einem Framework auch laufen – tut sie das, sollte die Umstellung der Umgebung auf einen eigenen Server mit mod_python oder FastCGI eben kein Problem darstellen. Und meine Shared-Hosting-Accounts bieten zumindest einen Python-Interpreter – nutzbar im cgi-bin – an.

[gerold]

Nur ging es mir darum, dass ich ein Python-Programm (z.B. eine Blog-Software oder ein Gästebuch oder oder oder) fertig in der Schublade liegen habe, das dann auf unterschiedlichen Zielplatformen läuft: Apache mit CGI, Apache mit FastCGI oder Apache mit mod_python.

Hi _kosmos_!

Es ist nicht alles WSGI was glänzt: http://karrigell.sourceforge.net/en/apache.htm

Viel Vergnügen!

mfg
Gerold

[_kosmos_]

Es ist nicht alles WSGI was glänzt: http://karrigell.sourceforge.net/en/apache.htm

LOL, dieses lustige Ding, was mit dem eigenen Webserver aufwartet und die Apache-Integration über mod_proxy und ein ErrorDocument, was den Webserver startet, abhandelt. Auf einem Shared-Host läuft das sicherlich nicht. Leider. Trotzdem vielen Dank!

_kosmos_

[Leonidas]

Und das explizierte Konfigurieren der URL-Dispatchings nervt mich gewaltig.

Komisch, ich hingegen fände es nervig (und auch unflexibel), wenn meine URLs dem Aufbau der App wiederspiegeln würden. Aber du kannst dir den Dispatcher selbst auchssuchen: es gibt viele WSGI-Dispatcher, dann wird es wohl auf einen geben, der dir entspricht.

Dennoch wäre es sehr angenehm, ein Framework zu finden, das keinen Webserver ausliefert um Neueinsteiger, denen ich Python im Web etwas näher bringen möchte, sehr schön.

Ok, einige Frameworks bringen welche mit, die du aber nicht nutzen musst. Mit WSGI bist du vom Adapter (eigener Webserver, FastCGI..) unabhängig.

Ja, darauf bin ich ja auch schon gekommen. Nur: Welches?
Ich habe mich jetzt mehere Tage mit Frameworks rumgeschlagen. web.py zum Beispiel produziert in der Download-Version Syntax-Fehler und in der SVN-Version funktioniert der WSGI-Kram nicht.

Hihi, ich sehe schon wie einige bestimmte Leute die hier mitlesen ein fettes "das ist so typisch web.py" Grinsen aufsetzen

Ich suche wie gesagt ein Framework, das ein Einsteiger "mal eben" per FTP auf seinen Webhost schiebt, eine Datei anlegt, in der er seine Klassen und Funktionen definiert und das Ganze dann sofort ohne großartige Konfiguration lauffähig ist...

Mit "mal eben" ist es leider noch nicht ganz so, weil die WSGI-Unterstützung außerhalb der Python-Welt bisher noch recht schwach ist (siehe mod_wsgi).
Von den Frameworks die es gibt sind einige besonders Erwähnenswert: Colubrid als kleines Framework, Paste als Inbegriff von WSGI, von dem viele Frameworks Code verwenden (dementspechend groß), Pylons als das populärste WSGI-Framework (ich würde schätzen irgendwo zwischen Django und TurboGears anzusiedeln, auch von der größe) und RhubarbTart als mehr nach WSGI ausgerichtetes CherryPy (welches eben auch so einen Dispatcher hat, wie du ihn haben möchtest). CharryPy eigentlich auch, unterstützt inzwischen ja auch WSGI.

[Leonidas]

LOL, dieses lustige Ding, was mit dem eigenen Webserver aufwartet und die Apache-Integration über mod_proxy und ein ErrorDocument, was den Webserver startet, abhandelt.

Spyce ist das gleiche, läuft aber auch ohne eigenen Webserver, d.h auch mit CGI, FastCGI und mod_python.

[_kosmos_]

Ach, gleich noch eine Frage: Gibt es WSGI-Frameworks, die Python 2.3 kompatibel sind? Einer meiner Hoster hat 2.3.5 und mein MAMP spinnt ein bisschen, was den Pfad zum Python Framework angeht. (/Library/Frameworks/Python.framework/Versions/2.4 auf Konsole, /System/Library/Frameworks/Python.framework/Versions/2.3/ in der error_log....)

[Leonidas]

Ach, gleich noch eine Frage: Gibt es WSGI-Frameworks, die Python 2.3 kompatibel sind? Einer meiner Hoster hat 2.3.5 und mein MAMP spinnt ein bisschen, was den Pfad zum Python Framework angeht.

Wenn ich mir die Bemerkung auf der Pylons Download-Seite ansehe, dann wird wohl Pylons (und somit wohl auch Teile von Paste, wenn nicht sogar das gesammte Paste) Python 2.3 kompatibel sein.

[jens]

Django und TurboGears sind schöne Frameworks, ehrlich. Jedoch kann man es fast vergessen, diese auf Shared-Webhosting-Umgebungen innerhalb von Apache aufzusetzen. Ohne Shell-Zugriff kann man das wohl gar nicht. (Von Zope mal ganz zu schweigen)

Nein das stimmt nicht wirklich. Zumindest django kann man ohne shell Zugriff benutzten. Allerdings muß man dabei einiges selber machen, weil die Entwickler einfach davon ausgehen das man eine shell hat.

Ich selber nutzte django auch in einer normalen Shared-Webhosting Probleme. Dazu hab ich einige Sachen, die man normalerweise in der shell machen muß (z.B. syncdb), per Web-Oberfläche in einem separaten _install Sektion erreichbar gemacht.
So kann man alles per FTP hochladen, geht in die _install Sektion und startet die installation.

Leider ist es von der offiziellen Seite nicht dokumentiert, wie das geht. Man muß sich also mit djangos interna ein wenig anfreunden...

[_kosmos_]

Leider ist es von der offiziellen Seite nicht dokumentiert, wie das geht. Man muß sich also mit djangos interna ein wenig anfreunden...

Könntest du hierzu vielleicht ein paar mehr Worte verlieren? Wie kann man diese _install-Section erreichen?


Liebe Grüße
_kosmos_

[jens]

Die _install Sektion bietet django nicht. Das hab ich selber gemacht, für PyLucid (ist mit django noch pre-Alpha).
sourcen:
http://pylucid.net/trac/browser/branche ... id/install
syncdb ist z.B. hier:
http://pylucid.net/trac/browser/branche ... install.py

Ein "syncdb" geht eigentlich so:

Code: Alles auswählen

from django.core import management
management.syncdb(verbosity=2, interactive=False)

Dummerweise benutzten die django Jungs aber dabei "print"... Also muß man sys.stdout umbiegen. Aber das geht ja recht einfach...

Generell sind viele oder alle (?) shell Sachen in ./django/core/management.py

Live kannst du dir das auch mal ansehen:
pylucid.de$_install$12345678$
Die $ zeichen durch / ersetzten, ohne www.

Allerdings ist pylucid.de gerade broken Die _install Sektion geht aber...

[_kosmos_]

Allerdings ist pylucid.de gerade broken Die _install Sektion geht aber...

Abgesehen davon, dass das Passwort per Pathinfo übergeben wird, sieht das doch schon sehr gut aus. Vielleicht hast du ja Lust dazu, einen Django-Core-Installer daraus zu bauen (nach dem Motto: INSTALLED_APPS =('django.core._install',), mit dem Ziel, dass diese Erweiterung auch vom Djangoprojekt aufgenommen wird oder eben als 3rd-Party-Patch, jedenfalls losgelöst von einer speziellen Anwendung (in dem Fall das CMS PyLucid).

Helfen würde ich dir gerne


Liebe Grüße
_kosmos_

[jens]

Daran hab ich eigentlich noch garnicht gedacht. Allerdings hab ich andere Baustellen bei PyLucid

Das mit dem Passwort in der URL stimmt schon, aber wie sonst absichern? Einfach kein Passwort? Ist auch doof... Eine .htaccess anlegen ist auch nicht jedermanns Sache...
Ich hatte das ganze schon mal Überlegt: http://pylucid.org/phpBB2/viewtopic.php?t=68

[_kosmos_]

So, ich wollte gerade Colurbrid ausprobieren....

Leider wenig erfolgreich. Meine ctest.cgi sieht so aus:

Code: Alles auswählen

#!/usr/bin/env python

from colubrid import BaseApplication, HttpResponse, execute
import os, sys


sys.path.append("/Library/Frameworks/Python.framework/Versions/Current/bin/")
sys.path.append("/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/")


class MyApplication(BaseApplication):

    def process_request(self):
        name = self.request.args.get('name', 'World')
        response = HttpResponse('Hello %s!' % name)
        response['Content-Type'] = 'text/plain'
        return response

app = MyApplication

if __name__ == '__main__':
    execute(app)

Und das gibt mein Apache als Fehlermeldung aus:

Code: Alles auswählen

[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] Traceback (most recent call last):
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Applications/MAMP/cgi-bin/ctest.py", line 22, in ?
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     execute(app)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Applications/MAMP/cgi-bin/colubrid/server.py", line 80, in execute
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     run()
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Applications/MAMP/cgi-bin/colubrid/server.py", line 63, in <lambda>
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     run = lambda: httpserver.serve(app, host=hostname, port=str(port))
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Library/Python/2.3/site-packages/Paste-0.9.7-py2.3.egg/paste/httpserver.py", line 578, in serve
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] ssl_context, int(threadpool_workers))
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Library/Python/2.3/site-packages/Paste-0.9.7-py2.3.egg/paste/httpserver.py", line 463, in __init__
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] RequestHandlerClass, ssl_context)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Library/Python/2.3/site-packages/Paste-0.9.7-py2.3.egg/paste/httpserver.py", line 445, in __init__
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] RequestHandlerClass, ssl_context)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/Library/Python/2.3/site-packages/Paste-0.9.7-py2.3.egg/paste/httpserver.py", line 266, in __init__
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     HTTPServer.__init__(self, server_address, RequestHandlerClass)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/SocketServer.py", line 330, in __init__
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     self.server_bind()
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/BaseHTTPServer.py", line 100, in server_bind
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     SocketServer.TCPServer.server_bind(self)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/SocketServer.py", line 341, in server_bind
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]     self.socket.bind(self.server_address)
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1]   File "<string>", line 1, in bind
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] socket.error: (48, 'Address already in use')
[Tue May 01 12:03:41 2007] [error] [client 127.0.0.1] Premature end of script headers: ctest.py

Wie es aussieht, will ctest.py – obwohl im CGI-Kontext aufgerufen – einen eigenen Server starten. Warum? Wer kann helfen?


Liebe Grüße
_kosmos_

[Leonidas]

Du musst ja auch Colubrid über einen WSGI-Gateway wie ``flup`` an Apache einbinden. So wie du es jetzt gemacht hast, startet es ja einen eigenen Server.
Wie man sowas einrichtet steht hier. Leider ist das flup trac down, aber runterladen kannst du es ja auch direkt vom Server.