Consigli sull'installazione / gestione dello stack WSGI?

Question

Dopo aver esaminato i molti utili e brillanti framework Python, trovo che nessuno di essi si avvicini a ciò di cui ho bisogno o fornisca via più dei miei bisogni. Sto cercando di mettere insieme qualcosa da solo; potrebbe definirlo come un framework, ma non full-stack. Tuttavia, non riesco a trovare online ciò che la comunità Python vede come il modo corretto / standard per gestire il middleware WSGI in un'applicazione.

Non sto cercando suggerimenti per il framework, a meno che non fornisca un esempio di come gestire il middleware WSGI. Né sto cercando informazioni su come convincere un server web a parlare con Python, quel poco che capisco.

Sto piuttosto cercando consigli su come dire a Python quali componenti / middleware mettere nello stack e in quale ordine. Ad esempio, se volessi usare:
La deposizione delle uova - > Memento - > AuthKit - > - > (?); MyApp
come potrei ottenere quei componenti nell'ordine giusto e come configurerei un elemento aggiuntivo (diciamo Rotte) prima di MyApp ?

; Potete consigliarmi sul modo comune / corretto / standard di gestire quale middleware è incluso in uno stack WSGI per un'applicazione Python?

Modifica
Grazie a Michael Dillon per aver raccomandato Un framework fai-da-te , che aiuta evidenzia il mio problema. La sezione middleware di quel documento afferma che si dovrebbe avvolgere il middleware A nel middleware B, B in C e così via:

app = ObjectPublisher(Root())
wrapped_app = AuthMiddleware(app)
from paste.evalexception import EvalException
exc_wrapped_app = EvalException(wrapped_app)

Il che mostra come farlo in un modo molto semplice. Capisco come funziona, tuttavia sembra troppo semplice quando si lavora con numerosi pacchetti di middleware.

Esiste un modo migliore per gestire il modo in cui questi componenti middleware vengono aggiunti allo stack? Forse un modello di progettazione comune che legge da un file di configurazione?

Answer 1

Questo è ciò che fa un framework. Alcuni framework come Django sono abbastanza rigidi e altri come i Piloni facilitano il mixaggio e l'abbinamento.

Poiché probabilmente prima o poi utilizzerai alcuni dei componenti WSGI del progetto Paste, potresti anche leggere questo articolo della gente di Paste su un Framework fai-da-te . Non sto suggerendo che dovresti andare a costruire il tuo framework, ma l'articolo fornisce una buona spiegazione di come funziona lo stack WSGI e di come vanno le cose insieme.

Answer 2

Devo dire che Apache / mod_wsgi è probabilmente il più "gestibile" delle configurazioni che ho usato.

nginx / fcgi è il più veloce, ma è un po 'un mal di testa.

Answer 3

Di quale middleware pensi di aver bisogno? Potrebbe non essere necessario includere alcun componente simile a "middleware" WSGI. Puoi perfettamente mettere insieme un "pseudo-framework" sciolto di librerie autonome senza la necessità di "avvolgere" l'applicazione nel middleware.

(Personalmente utilizzo una libreria di lettura dei moduli, un livello di accesso ai dati e un motore di template separati, nessuno dei quali si conoscono o devono iniziare a giocherellare con il environment WSGI).

Answer 4

Il mio consiglio è di leggere il PEP su WSGI, in particolare il parte su middleware . Se hai una domanda su qualcosa con le parole "standard" e "WSGI" in esso, la risposta è lì o stai ponendo la domanda sbagliata.

Answer 5

Se ti è piaciuto il tutorial del Do-It-Yourself-Framework menzionato prima, ma vuoi gestire queste cose in un file di configurazione, Incolla Distribuisci sarebbe la risposta ovvia. (È menzionato nel tutorial, ma solo brevemente nell'ultimo paragrafo).

Questo è ciò che usa il framework Pylons, tra l'altro (e anche Turbogears 2, che è basato su Pylons).

Answer 6

" sembra troppo semplice quando si lavora con un numero di pacchetti middleware. "

Quanto è grande un numero?

Non lavorerai con centinaia o migliaia.

Sarà (a) un piccolo numero (sotto una dozzina) e (b) il "diritto" l'ordine non è magico.

Ogni pezzo di middleware avrà un lavoro molto, molto specifico e requisiti molto specifici per ciò che deve venire prima di esso.

È molto meno confuso di quanto si supponga.