2010-01-29 8 views
10

Da quello che posso direche è un server di sviluppo wsgi python minimalista con supporto per il ricaricamento del codice?

  1. wsgiref - nessun codice ricarica
  2. CherryPy - più di un semplice server
  3. mod_wsgi - tutte le spese generali apache
  4. paste.httpserver - pasta è un pacchetto enorme con altre cose in esso
  5. flup - come pasta, troppa roba.
  6. Spawning - mai usato ma sembra abbastanza leggero.
  7. Tornado - non proprio WSGI + "quadro" completo
  8. Werkzeug - RunCommand

eventuali altri là fuori? quale preferisci?

+0

Apache non ha l'overhead che molti sostengono di avere. Se lo configuri e lo usi correttamente, che la maggior parte delle persone non lo fa, non è così male come la gente lo fa. Sfortunatamente le persone che non conoscono meglio continuano a diffondere questo mito sul fatto che Apache sia gonfia. :-( –

+0

Graham, per favore non fraintendermi, mi piace molto Apache e (penso) Sono bravo a configurarlo Sono totalmente d'accordo sulla maggior parte degli apache-odiatori sono persone che non sanno come farlo funzionare. Comunque le mie intenzioni qui sono totalmente diverse Voglio fornire agli altri sviluppatori del mio team un semplice file requirements.txt per farle funzionare e POI distribuire in mod_wsgi, in questo modo le persone non devono imparare e configurare la propria istanza di sviluppo Apache. –

+0

Sto cercando la stessa soluzione dell'OP. FWIW: il mio problema con Apache è che non sta funzionando bene con diversi moduli importati - come Shapely. Voglio continuare con Dev della mia app wsgi (con ricaricamento) mentre io Esegui il debug del problema Apache separatamente. –

risposta

4

Uno si potrebbe desiderare di guardare è Werkzeug - è un toolkit di utilità WSGI. Include una funzione runserver che prende il server wsgiref e aggiunge il ricaricamento automatico del codice (puoi anche configurarlo per ricaricarlo quando i file di configurazione cambiano) e un fantastico debugger.

Su una nota a margine, il tuo disprezzo per i framework fa sembrare che stai pianificando di gestire tutte le cose WSGI da zero, nel qual caso ti consiglierei di utilizzare le funzioni di utilità di Werkzeug per gestire le richieste di analisi e generare risposte. È molto più divertente che farlo da solo. (E per l'amore di Guido, PER FAVORE, non usare cgi.FieldStorage!)

+0

Non ho niente di frameworks, infatti sono un grande contributore di TurboGears che dice che devi usare lo strumento giusto per il lavoro e in questo caso installare paste sembra un enorme pacchetto solo per i test –

+0

Ok, immagino di aver semplicemente interpretato male il tuo fraseggio. Mi dispiace per quello – LeafStorm

+1

In ritardo per la festa, ma cosa c'è di sbagliato nell'usare cgi.FieldStorage? Un tutorial consigliato usando qualcosa come 'cgi.FieldStorage (fp = environ ['wsgi.input'], environ = environ)', e funziona. – noamtm

1

Finora ho usato CherryPy e paragonato a Django (che, pur non nella tua lista, è l'unico altro server di sviluppo che ho usato) Mi piace molto più. Fa quello che dice: è lì solo quando ne hai bisogno, e si toglie di mezzo per il resto del tempo.

Utilizzare Django sembrava come se avessi bisogno di iscrivermi al modo di fare Django. Anche se Django offre un sacco di funzionalità in più (interfaccia di amministrazione predefinita, widget sulle tue pagine web), l'uso di CherryPy sembra essere solo un'altra importazione che ha una funzionalità molto buona (spesso ti sorprende con extra).

+2

se ti piace il cherrypy allora amerai WebError. Detto questo sembra che tu stia mescolando "web framework" con "web server". –

1

Si consiglia di incollare o CherryPy. Sono i più facili da usare.

1

Un modo veramente semplice è CGI (insieme a un server Web regolare e utilizzando wsgiref.handlers.CGIHandler). Terribile per le prestazioni su un server di produzione, ma ottimo per lo sviluppo. È possibile scrivere un singolo script che funzioni sia come mod_wsgi WSGIScriptAlias ​​(che espone un oggetto application), sia come mod_cgi ScriptAlias ​​(chiamando wsgiref quando __name__=='__main__').

Molti ambienti WSGI hanno un modo per ricaricare lo script di base, ad esempio WSGIScriptReloading di mod_wsgi, che è attivo per impostazione predefinita. Sfortunatamente, è probabile che tu stia inserendo gran parte del codice nei moduli, il che non è così facile da ricaricare. In mod_wsgi puoi anche farlo inviando un SIGINT per eseguire un ricaricamento quando sei in modalità demone. Sfortunatamente devi ancora annusare ogni modulo che stai usando per gli aggiornamenti di mtime per sapere se devi ricaricare. E non funziona in modalità incorporata.

Un approccio disordinato ma fattibile è quello di annusare tutti i moduli che fanno parte dell'applicazione, e se qualcuno è stato aggiornato dall'ultimo controllo, ricaricarli tutti.Devi ricaricarli in una volta, rimuovendoli tutti dalla ricerca sys.modules (rimuovi anche le voci valutate None mentre sei lì, per evitare problemi relativi alla ricerca delle importazioni), in modo da assicurarti che non mantengano i riferimenti incrociati a le vecchie versioni di se stessi. E ovviamente non devono lasciare altri riferimenti a se stessi al di fuori della vostra applicazione. È possibile vedere un esempio di questo in azione nella classe ModuleUpdaterhere.

(Questo software non è pronto per il rilascio, ma ha fornito il modulo di ricarica per le mie app WSGI per alcuni anni e sembra stabile. L'idea è di mettere tutta l'app WSGI in una classe di applicazione in un pacchetto , che è possibile importare da un singolo script punto di ingresso WSGI/CGI/a riga di comando, si include la configurazione distribuzione in quello script)

+0

Sembra che tu stia reinventando ciò che fanno tutti i moduli precedenti, ad esempio Spawning implementa il tuo algoritmo per il ricaricamento del codice. Detto questo, non sto cercando di avviare un'altra implementazione. –

+0

Non esattamente reinventare; Sto usando questo più a lungo di quanto è esistito lo spawning! La differenza rispetto ad altre che conosco è che l'implementazione WSGI è praticamente tutto ciò che fa questo modulo; non trascina un server o un framework di app nell'equazione. – bobince

+0

Non voglio combattere, ma paste.reloader è ancora più vecchio di Spawning. Il mio punto originale è che si punta al proprio codice che non è ufficialmente rilasciato in pypi, si dice che è stabile eppure non lo si sostiene (o almeno così sembra) –

4

Partenza run_simple da Werkzeug:

http://werkzeug.pocoo.org/documentation/0.5.1/serving.html

in aggiunta. per darti il ​​ricaricamento automatico del codice, puoi usare use_debugger = True per includere la loro bella spi ffy debugger nella parte superiore della tua app (che include la console in ogni riga del traceback).

0

È possibile utilizzare paste.reloader con qualsiasi wsgi-server, oltre ad altri moduli di pasta.

 
# run paste reloader 
import paste.reloader as reloader 
reloader.install() 

# run wsgiref server 
from wsgiref import simple_server 
simple_server.make_server('', 8080, main_wsgi_app).serve_forever() 

È abbastanza minimalista?

+0

Sembra promettente. Ma i documenti paste.reloader (http://pythonpaste.org/modules/reloader.html) sembrano dire che devi avvolgere questo in uno script di shell in loop. In altre parole, sembra che il "reloader" esca semplicemente dalla chiamata server_forever() al cambio di codice; il chiamante ha ancora bisogno di invocare il ricaricamento tramite un ciclo. Sì? –

1

Inoltre, ti sei perso web.py, che è sia piccolo che supporta il caricamento del codice.

Problemi correlati