2010-01-29 7 views
10

De lo que puedo decirque es un servidor de desarrollo python wsgi minimalista con soporte para recargar código?

  1. wsgiref - hay un código de recarga
  2. CherryPy - más que el servidor
  3. mod_wsgi - todos los gastos indirectos Apache
  4. paste.httpserver - pasta es un gran paquete con otras cosas en él
  5. flup - igual que pegar, demasiadas cosas.
  6. Desove: nunca lo usó, pero parece lo suficientemente liviano.
  7. Tornado - no es realmente wsgi + "marco" lleno
  8. Werkzeug - runcommand

cualquier otros por ahí? ¿cual prefieres?

+0

Apache no tiene la sobrecarga que muchos afirman tener. Si lo configura y lo usa correctamente, lo que la mayoría de las personas no hace, entonces no es tan malo como las personas lo hacen. Desafortunadamente, las personas que no conocen nada siguen propagando este mito sobre Apache que está hinchado. :-( –

+0

Graham, por favor no me malinterpreten. Realmente me gusta apache y (creo) soy bueno configurándolo. Estoy totalmente de acuerdo en que la mayoría de los que odian apache son personas que no saben cómo hacerlo. Sin embargo, mis intenciones aquí son totalmente diferentes. Quiero proporcionar a otros desarrolladores de mi equipo un archivo simple requirements.txt para ejecutarlos y luego implementarlo en mod_wsgi, de esta forma las personas no tienen que aprender y configurar su propia instancia de apache de desarrollo. –

+0

Estoy buscando la misma solución que el OP. FWIW: mi problema con Apache es que no funciona bien con varios módulos importados, como Shapely. Quiero continuar el desarrollo de mi aplicación wsgi (con recarga) mientras solucione el problema de Apache por separado. –

Respuesta

4

Uno que es posible que desee consultar es Werkzeug - es un kit de herramientas de utilidad WSGI. Incluye una función runserver que toma el servidor wsgiref y agrega la recarga automática de código (también puede configurarlo para volver a cargar cuando cambian los archivos de configuración) y un impresionante depurador.

En una nota lateral, su desprecio por los marcos hace sonar como si estuviera planeando manejar todo el material de WSGI desde cero, en cuyo caso recomendaría utilizar las funciones de utilidad de Werkzeug para gestionar las solicitudes de análisis y generar respuestas. Es mucho más divertido que hacerlo tú mismo. (¡Y por amor a Guido, POR FAVOR no use cgi.FieldStorage!)

+0

No tengo nada contra frameworks. De hecho, soy un gran colaborador de TurboGears que dice que necesita usar la herramienta correcta para el trabajo y en este caso obtener pegado instalado parece un gran paquete solo para probar –

+0

Está bien, supongo que acabo de malinterpretar tu fraseo. Lo siento por eso. – LeafStorm

+1

Tarde a la fiesta, pero ¿qué hay de malo con el uso de cgi.FieldStorage? Un tutorial recomienda usar algo como 'cgi.FieldStorage (fp = environ ['wsgi.input'], environ = environ)', y funciona. – noamtm

1

Hasta ahora he estado usando CherryPy, y comparado con Django (que, aunque no está en su lista, es el único otro servidor de desarrollo que utilicé) Me gusta mucho más. Hace lo que dice: solo está allí cuando lo necesita y se quita del camino por el resto del tiempo.

El uso de Django me pareció necesario para suscribirme a la forma de hacer las cosas de Django. Aunque Django proporciona montones más de funcionalidad de fábrica (interfaz de administrador predeterminada, widgets en sus páginas web), usar CherryPy parece ser solo otra importación que tiene una funcionalidad muy buena (a menudo sorprendentemente con extra).

+2

si te gusta el cherrypy, entonces te encantará WebError. Dicho eso, parece que estás mezclando "framework web" con "servidor web". –

1

Recomiendo pegar o CherryPy. Son los más fáciles de poner en funcionamiento.

1

Una forma realmente fácil es CGI (junto con un servidor web normal, y usando wsgiref.handlers.CGIHandler). Terrible para el rendimiento en un servidor de producción, pero excelente para el desarrollo. Puede escribir un único script que funcione como un mod_wsgi WSGIScriptAlias ​​(exponiendo un objeto application), y como un mod_cgi ScriptAlias ​​(llamando al wsgiref cuando __name__=='__main__').

Muchos entornos WSGI tienen una forma de volver a cargar el script básico, por ejemplo, WSGIScriptReloading de mod_wsgi, que está activado por defecto. Desafortunadamente, es probable que coloques gran parte de tu código en módulos, lo que no es tan fácil de volver a cargar. En mod_wsgi también puede hacerlo enviando un SIGINT para realizar una recarga cuando esté en modo daemon. Lamentablemente, todavía tiene que olfatear cada módulo que está utilizando para las actualizaciones de mtime para saber si debe volver a cargar. Y no funciona en modo incrustado.

Un enfoque desordenado pero factible es olfatear todos los módulos que son parte de su aplicación, y si alguno se ha actualizado desde la última comprobación, vuelva a cargarlos todos.Tienes que volver a cargarlos de una vez, quitándolos todos de la búsqueda sys.modules (elimina también las entradas de valor None mientras estás allí, para evitar problemas relativos de búsqueda de importación), para garantizar que no mantengan referencias cruzadas las versiones antiguas de ellos mismos. Y, por supuesto, no deben dejar otras referencias a sí mismos fuera de su aplicación. Puede ver un ejemplo de esto en acción en la clase ModuleUpdaterhere.

(Este software no está listo para su lanzamiento, pero ha estado proporcionando recarga de módulos para mis aplicaciones WSGI desde hace unos años y parece ser estable. La idea es poner toda su aplicación WSGI en una clase de aplicación en un paquete , que se puede importar desde un único/script punto de entrada WSGI/CGI de línea de comandos; se incluye la configuración de despliegue en ese guión)

+0

Parece que está reinventando lo que hacen todos los módulos anteriores, por ejemplo, Spawn implementa su algoritmo para la recarga de código. Dicho esto, no estoy buscando comenzar otra implementación. –

+0

No exactamente reinventando; ¡He estado usando esto por más tiempo de lo que Spawning ha existido! La diferencia con otras que conozco es que la implementación de WSGI es prácticamente todo lo que hace este módulo; no arrastra un marco de servidor o aplicación en la ecuación. – bobince

+0

No quiero pelear, pero pegar.reloader es incluso más antiguo que Spawning. Mi punto original es que apuntas a tu código que no está oficialmente lanzado en pypi, dices que es estable pero no te quedas atrás (o al menos eso parece) –

4

salida run_simple de werkzeug:

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

Además. para darle recarga automática de código, puede usar use_debugger = True para incluir sus bonitos spi ffy depurador en la parte superior de su aplicación (que incluye la consola en cada línea de la trazabilidad).

0

Puede usar paste.reloader con cualquier servidor wsgi, además de otros módulos de pegado.

 
# 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() 

¿Es eso lo suficientemente minimalista?

+0

Parece prometedor. Pero los documentos paste.reloader (http://pythonpaste.org/modules/reloader.html) parecen decir que tiene que ajustar esto en un script de shell en bucle. En otras palabras, parece que el "recargador" simplemente sale de la llamada server_forever() ante un cambio de código; la persona que llama aún necesita invocar la recarga a través de un bucle. ¿Sí? –

1

Además, ha omitido web.py, que es pequeño y admite la recarga de código.

Cuestiones relacionadas