Das deutsche Python-Forum

hallo zusammen,

würde gerne den webauftritt mit django machen und habe mich schon mal damit beschäftigt. die installation zu hause (linux, suse 10.2) lief problemlos - natürlich. testen mit hilfe des eingebauten webservers funzt auch, aber wie schaffe ich es jetzt, dass die seite auch im netz zu sehen ist.

provider bietet apache 2.0.54 mit mod_python, das auch funktioniert - zumindest lief ein einfaches mod_python script. Aber wenn ich im python-script "import django..." eingebe erhalte ich natürlich einen Fehler, da es ja dort nicht installiert wurde. Nur, wie soll ich das machen, bin ja nicht der herrscher über den apache???
----------------------------
danke im voraus

Du musst Django zusammen mit deiner Anwendung in deinem Account installieren und dann für mod_python entsprechend den Python-Path passend setzen. Das ist die Highlevel-Hilfe, die ich anbieten kann.

Stefan

Ich würde das ganze erstmal mit CGI Probieren und wenn das läuft auf mod_Python umstellen.
Nützlich ist es auch ein kleines CGI Skript zu schreiben um syncdb aus zu führen.

Das dumme ist nur, django beinhaltet keinen eigenen CGI Server, den man braucht. In PyLucid nutzte ich den aus dem ticket http://code.djangoproject.com/ticket/2407
http://trac.pylucid.net/browser/trunk/p ... _server.py

Evtl. ist auch die PyLucid hilfreich, weil es ein wenig auf Shared-Webhosting ausgelegt ist. Installationsanleitung ist hier: http://pylucid.org/_goto/107/install-PyLucid/

Hab die PythonPath - Direktive in .htaccess eingetragen und ein Miniscript laufen lassen - ohne Error - grandios. Bevor ich nun Django rüber kopieren wollte sah ich mir mal an, was da so an Speicher flöten geht - bei mir auf der Platte sind das satte 62MB!!! (incl. eines Django0.97 - Ordners den man woh nicht benötigt ODER???)

1. Muss man das ganze Paket rüber spielen oder genügt nur das Modul, welches man im import einbindet?

2. Wenn das ganze Paket kopiert werden muss, dann sollte ich nach etwas Schlankerem Ausschau halten, gibts da was?

thanks

62MB? Da stimmt aber was nicht. Untersuche mal, was du da alles hast.

Django ist groß, aber nicht so groß. Bei mir hat die SVN-Version 26MB (inkl. ".svn"-Verzeichnissen). Dabei macht das "conf"-Verzeichnis 16MB aus und sind es die ganzen Sprachdateien für das Admin-UI. Wenn dir Englisch reicht, kannst du das alles weglassen. Nächstgrößeres Verzeichnis ist "contrib" mit 4,9MB. 1,9MB kostet das Admin-UI, 1,2MB nochmal "localflavors", was glaube ich auch mit der Internationalisierung zu tun hat. Aus "core" (1,2MB) wird man wenig löschen können, aber aus "db" (1,4MB) könnte man nicht benötigte Datenbank-Backends löschen. Der Rest ist eigentlich Kleinvieh.

Wenn du etwas wirklich Kleines (dafür mit schlechter Dokumentation) haben willst, wie wäre es mit web.py? Wie groß Werkzeug ist, kann ich nicht sagen. Letztes ist aber kein vollständiges Webrahmenwerk wie Django. Und ich denke nicht, das Pylons wirklich kleiner ist - von Zope/Grok gar nicht zu reden :)

Stefan

sma hat geschrieben:Wenn du etwas wirklich Kleines (dafür mit schlechter Dokumentation) haben willst, wie wäre es mit web.py?

Gibt es überhaupt noch jemanden der das nutzt? Reddit hat das mal genutzt wenn ich mich richtig erinnere, aber seitdem AaronSw nicht mehr für die arbeitet sind die inzwischen auch bei Pylons angelangt.
Zur Erheiterung kann ja dieses Zitat dienen: [wiki]IRC_Channel/Zitate#WebPyOnpythonWeb[/wiki], aber ich würde es mir wirklich zweimal überlegen, ob ich auf etwas setze, wo die Community nicht sonderlich dahinter steht.

sma hat geschrieben:Und ich denke nicht, das Pylons wirklich kleiner ist

Pylons selbst ist sicherlich kleiner, aber es hat eine ganze Menge Dependencies ohne die es nicht richtig funktioniert, ich lerne da immer was es für neue Module im Cheeseshop gibt, weil Pylons die gerne mitzieht.

sma hat geschrieben:Wie groß Werkzeug ist, kann ich nicht sagen. Letztes ist aber kein vollständiges Webrahmenwerk wie Django.

Werkzeug selber sind 6567 Zeilen Python und 1.2MB Dateien. Da fehlt natürlich noch ein wenig Zubehör. Wenn du noch eine Template Engine wie Jinja2 dazu tust kannst du da 4591 Zeilen und 700KB dazu tun. Eine kleine Template Engine ist aber auch schon bei Werkzeug dabei wenn es nichts großes sein soll. Für den richtigen Datenbank Spaß empfiehlt der Profi SQLAlchemy, das ist in der 0.4.4er version 22365 Zeilen und 3.6MB.

Das sind die Dependencies die LodgeIt! braucht, LodgeIt kommt in der aktuellen Version auf 1089 Zeilen ohne Templates und 2.9MB (Templates + Bildchen und Fonts fürs Captcha).

(Dateigrößen inkl. pyc Dateien)

Bei alle dem sollte man auch bedenken das WebSpace im GB Bereich nicht wirklich Geld kostet

Vielen Dank für die Hilfe,

tja, ich habe web.py schon probiert, aber war mit mod_python und der apache - inst des providers nicht zum laufen zu bewegen.

Also ich muss noch erwähnen, dass die Seite für einen Verein erstellt werden soll, der aus welchen Gründen auch immer den Provider nicht wechseln kann und will, weil kostenlos. Dort werden allerdings nur 10 - 50Megabytes angeboten.

Ich weiß selbst dass das nicht üppig ist, aber der Kunde is König...

Tja, momentan befinden sich etwa 30MB Daten dort, so dass mir letztlich müde 20MB zur Verfügung stehen.

Macht dann so etwas überhaupt Sinn, oder ist es dann doch besser das bisschen Zeugs selbst zu stricken, da ja doch viel Statisches dabei ist?

Ich würde sagen, wenn du nicht ausschließlich statische Seiten hast sondern - wie ich vermute - Seiten, die aus den 30 MB Daten da nach Benutzereingaben zusammengestellt werden, ist es sinnvoll, einen dynamischen Ansatz zu fahren. Eine Alternative könnte sein, statische Seiten mit einem Programm auf deinem eigenen Rechner zu generieren und dann diese hochzuladen. Nicht so flexibel, aber du verlierst nicht komplett den Vorteil von dynamischen Seiten, etwa dass du das Layout prinzipiell für alle Seiten an nur einer Stelle ändern kannst.

Stefan

sma hat geschrieben:Eine Alternative könnte sein, statische Seiten mit einem Programm auf deinem eigenen Rechner zu generieren und dann diese hochzuladen.

Das kann durchaus eine gute Alternative sein, jedoch solle man sich bewusst sein, dass man mit diesem Ansatz unter Python so ziemlich auf dem Trockenen steht, denn bis auf die Blog-Engine firedrop2 gibt es kaum Tools die einem dabei helfen, statische Seiten zu generieren.

Irgendwann möchte ich sowas in PyLucid einbauen. Aber das dürfte noch einige Zeit dauern...

jens hat geschrieben:Irgendwann möchte ich sowas in PyLucid einbauen. Aber das dürfte noch einige Zeit dauern...

Auf die schnelle kann man auch eine Seite lokal aufsetzen und sie dann mit HTTrack statisch machen.

Ja, stimmt, das hatte ich auch schon einmal gedacht. Ich wollte dazu mal eine Anleitung schreiben...