deployment/wsgi

[keppla]

Hallo Forum!

Ich stehe vor der Wahl, wie ich ein Projekt der Öffentlichkeit verfügbar machen möchte.
Wie ist es euch am liebsten, WSGI-applikationen angeboten zu bekommen?

Das Projekt hat Abhängikeiten zu Werkzeug und Jinja, bei Bedarf zu mysql.

[jens]

Ich biete PyLucid in zwei Varianten an. Einmal mit Abhängigkeiten und einmal ohne... Dann kann jeder selbst entscheiden

[EnTeQuAk]

Um dich nicht selber noch mit der Pflege mitgelieferter Libraries zu beschäftigen, würde ich einfach ohne Libraries ausliefern, diese aber ausführlich erleutern und eine Installationsanleitung beilegen.


Ansonsten das Übliche:

tar.gz, zip, Egg und beim Käseladen eintragen. Nach möglichkeit, das Entwicklungs-Repository öffnen.


Mehr fällt mir grad net ein.


MfG EnTeQuAk

[keppla]

Danke erstmal für die Antworten,

Um dich nicht selber noch mit der Pflege mitgelieferter Libraries zu beschäftigen, würde ich einfach ohne Libraries ausliefern, diese aber ausführlich erläutern und eine Installationsanleitung beilegen.

Irgendwie wirkt das nicht sonderlich nutzerfreundlich, finde ich. Eigentlich wollte ich aber weniger darauf raus, ob ich Abhängigkeiten mitliefere oder nicht, sondern eher, was ich mache, dass die Webspacebesitzer nachher nicht (berechtigerweise) sagen "mit php is das aber immer einfacher".

Ich hab mich mal etwas von pylucid inspirieren lassen, und hab eine passende .htaccess für fcgi und cgi angelegt. Es ist somit möglich, dass man den Kram einfach hochlädt, und "gut is".
Allerdings fällt mir da
a) keine gute Lösung für mod_python ein, und
b) find ich das rewrite etwas hässlich (dass alles sichtbar nach "index.fcgi/mein/urls" umgewandelt wird). Geht das irgendwie "hübscher"?

tar.gz, zip, Egg und beim Käseladen eintragen. Nach Möglichkeit, das Entwicklungs-Repository öffnen.

Hab ich vor

[BlackJack]

Letztlich ist das mit PHP immer einfacher. Ich würde Python da einfach nicht als Konkurrenz zu PHP sehen, sondern eher in der Profiliga ansiedeln. Ein JBoss läuft bei den Billighostern ja auch nicht so einfach.

[Leonidas]

a) keine gute Lösung für mod_python

Es gibt keine gute Lösung für mod_python, weil mod_python an sich schon keine gute Lösung ist.

[keppla]

Letztlich ist das mit PHP immer einfacher. Ich würde Python da einfach nicht als Konkurrenz zu PHP sehen, sondern eher in der Profiliga ansiedeln.

Nicht, dass ich falsch verstanden werde: ich HASSE php, unter anderem, weil ich es von der Arbeit her benutzen muss.
Allerdings finde ich, dass für Endnutzer (und in meinem fall sind das durchaus die "ich hab webspace"-kiddies) es bei der installation einfach haben sollten, und da ist "einfach Reinkopieren" einfacher als "erstmal rauskriegen, wie ich das installiere".

Ein JBoss läuft bei den Billighostern ja auch nicht so einfach.

Und das macht es besser? Wäre PHP auf einmal Professionell, wenns schwerer zu installieren wäre?

Es gibt keine gute Lösung für mod_python, weil mod_python an sich schon keine gute Lösung ist.

Das hab ich befürchtet. Bleibt zu hoffen, dass "mod_wsgi" irgendwann mal in debian-stable landet.

[Y0Gi]

Es ist nicht unüblich, je ein (meist sehr einfaches) Script beizulegen, dass die Applikation für CGI, FastCGI, SCGI (beide via flup) und mod_wsgi (`application` muss daraus importierbar sein) nutzbar macht. Wenn du ganz viel Langeweile hast, legst du noch Beispielconfig-Abschnitte für Apache, Lighty usw. mit dazu.

[jens]

@Y0Gi: Dieses Skript funktioniert nur auf der Konsole mit root Rechten?

[Leonidas]

mod_wsgi ist in Lenny, also wird es höchstwahrscheinlich Teil des nächsten Stable-Releases. Zu dem ist es vermutlich auch nicht mehr so weit (also vergleichen mit den Abständen zwischen Woody und Sarge). It's done when it's done und in diesem Fall muss auch ich zugeben, dass es mir zu Lenny nicht besonders eilig ist. Würde lieber Python 2.5 als Standard-Python in Lenny sehen oder gar schon Python 2.6 (wobei, das wird es mit hoher Wahrscheinlichkeit nicht zum Default-Python schaffen, wenn es überhaupt bis da released ist).

[Y0Gi]

@Y0Gi: Dieses Skript funktioniert nur auf der Konsole mit root Rechten?

Das für CGI nicht; die für FastCGI und SCGI nur, wenn ein Port < 1024 benutzt werden soll. Der Apache muss aber entsprechend konfiguriert sein, was ohne Rootrechte selten möglich ist. Das Script für mod_wsgi braucht ebenfalls keine Rootrechte und sofern der Apache entsprechend vorbereitet ist, kann ein User auch ohne Rootrechte mod_wsgi nutzen. birkenfeld hat dazu irgendwo im Pocoo-Repo einen racc/racd(?) rumfliegen, dere mod_wsgi für Masshosting benutzbar macht, iirc.

[sma]

Ich stehe vor der Wahl, wie ich ein Projekt der Öffentlichkeit verfügbar machen möchte.
Wie ist es euch am liebsten, WSGI-applikationen angeboten zu bekommen

Aus Anwendersicht möchte ich in der Regel etwas haben, das sofort funktioniert. Dazu ziehe ich auch gerne ein bisschen mehr. Auspacken, starten, muss laufen. Wenn nicht, dann Tonne. Dann darf gerne in einem README noch beschrieben sein, wie man die Anwendung möglicherweise anders in eine bestehende Infrastruktur integriert.

Ich würde daher vorschlagen, das Projekt in einer Version mit allen abhängigen Bibliotheken und einem Python-Webserver für WSGI auszuliefern und es so vorzukonfigurieren, dass es direkt startbar ist, wenn man Python 2.5 installiert hat. Auch eine Datenbank will ich nicht extra aufsetzen oder konfigurieren müssen.

Wenn ich erst eine manuelle Installation vornehmen musss, muss ich im Vorfeld schon sehr von der Qualität und Nützlichkeit des Projekts überzeugt sein, um mir diese Mühe zu machen. Und je stärker das Projekt auf Endanwender und nicht auf Entwickler zugeschnitten ist, desto stärker wird diese Haltung vorherrschen.

Stefan

[apollo13]

@sma: Ich denke, dass das jeder gerne anders hätte: Ich zum Beispiel könnte jeden Entwickler erschlagen, der via svn-externals gleich noch django zu seiner app dazu packt. (gleiches gilt für andere dependencies, wofür gibts den setuptools?)

MfG apollo13

[keppla]

Aus Anwendersicht möchte ich in der Regel etwas haben, das sofort funktioniert. Dazu ziehe ich auch gerne ein bisschen mehr. Auspacken, starten, muss laufen. Wenn nicht, dann Tonne.

Sehe ich auch so, das Problem dabei ist...

Ich würde daher vorschlagen, das Projekt in einer Version mit allen abhängigen Bibliotheken und einem Python-Webserver für WSGI auszuliefern und es so vorzukonfigurieren, dass es direkt startbar ist, wenn man Python 2.5 installiert hat.

...das ist leider nicht "sofort startbar", zumindest nicht für die webspacenutzer.

Ich bin zZ soweit, dass ich ein archiv habe, in dem sich folgendes befindet:

skarabaeus (mein projekt)
werkzeug
jinja
flup
index.cgi
index.fcgi
app.py (die datei, in der die wsgi-instanz erzeugt wird, hier kann man auch die konfiguration vornehmen)
run_standalone.py
.htaccess-fcgi
.htaccess-cgi

Die installation läuft wie folgt:

• entpacken
• app.py anpassen
• für standalone-nutzer: python run_standalone
  für apache/(f)cgi-nutzer: richtige .htaccess-??? in .htaccess umbenennen
  für den wsgi-puristen: from app import app

@sma: Ich denke, dass das jeder gerne anders hätte: Ich zum Beispiel könnte jeden Entwickler erschlagen, der via svn-externals gleich noch django zu seiner app dazu packt. (gleiches gilt für andere dependencies, wofür gibts den setuptools?)

Dem würde ich entgegenwirken, indem ich wie anfangs erwähnt, das ganze einmal in "rundum glücklich" und einmal in "minimalistisch" anbiete.

[sma]

@sma: Ich denke, dass das jeder gerne anders hätte: Ich zum Beispiel könnte jeden Entwickler erschlagen, der via svn-externals gleich noch django zu seiner app dazu packt. (gleiches gilt für andere dependencies, wofür gibts den setuptools?)

Ich glaube, ich habe das "WSGI" ein bisschen überlesen und dachte allgemein an eine Anwendung für Endanwender, die sie sich lokal installieren wollen.

Um's bei einem Hoster zu installieren, ist direkte Lauffähigkeit natürlich nicht notwendig. Meine Sicht der Welt ist leider, dass WSGI-Anwendungen nicht so einfach zu hosten sind, es gibt da keinen etablierten Standard wie z.B. bei Java-Anwendungsservern mit .war-Dateien.

Ein SVN-Link käme aber aus meiner Sicht niemals in Frage, weil ich fertige Software nicht aus einem SVN beziehen wollen würde, sondern traditionell per Download eines Archivs.

Stefan

[mitsuhiko]

Standardweg: gutes setup.py und keine Dependencies. Du kannst zusätzlich natürlich noch gerne eine all-in-one Lösung machen, aber nicht anders rum. Das nervt jeden Systemadministrator.

TextPress zb bringt eine textpress.cgi, textpress.fcgi und textpress.wsgi mit, aber keine .htaccess aus naheliegenden Gründen. Denn a) ist mod_rewrite die schlechteste Lösung um eine WSGI Anwendung and die richtige URL zu bunden und ist b) das von Betriebssystem zu Betriebssystem anders zu verwenden. Oft sind auch .htaccess gar nicht erst aktiviert da langsam.

[keppla]

Standardweg: gutes setup.py und keine Dependencies.

diesen Basisweg wollte ich definitv anbieten. Nur hab ich dazu irgendwie keine fragen

Denn a) ist mod_rewrite die schlechteste Lösung um eine WSGI Anwendung and die richtige URL zu bunden und ist b) das von Betriebssystem zu Betriebssystem anders zu verwenden.

gibts für cgi/fcgi eine schönere?

Oft sind auch .htaccess gar nicht erst aktiviert da langsam.

Das typische Publikum für diese .htaccess-dateien, was ich vor augen hatte, waren die webspace-user, und auf webspaces sind die afaik eigentlich immer möglich.

[mitsuhiko]

Denn a) ist mod_rewrite die schlechteste Lösung um eine WSGI Anwendung and die richtige URL zu bunden und ist b) das von Betriebssystem zu Betriebssystem anders zu verwenden.

gibts für cgi/fcgi eine schönere?

FastCGI hoster bieten häufig Regel Shell Zugriff an oder haben ein Control-Panel wo man die Scripte verwaltet (und neustartet).

Oft sind auch .htaccess gar nicht erst aktiviert da langsam.

Das typische Publikum für diese .htaccess-dateien, was ich vor augen hatte, waren die webspace-user, und auf webspaces sind die afaik eigentlich immer möglich.[/quote]
Aber die erlauben dann nur ein Subset von .htaccess. zB geht SetHandler so gut wie nie.

[keppla]

FastCGI hoster bieten häufig Regel Shell Zugriff an oder haben ein Control-Panel wo man die Scripte verwaltet (und neustartet). ... Aber die erlauben dann nur ein Subset von .htaccess. zB geht SetHandler so gut wie nie.

Ach mist. Gut zu wissen.
Da bleibt dann wohl nur zu hoffen, dass sich mod_wsgi ö.Ä. irgendwann mal als standard durchsetzt.