views:

406

answers:

7

From what I can tell

  1. wsgiref - no code reload
  2. CherryPy - more than just the server
  3. mod_wsgi - all the apache overhead
  4. paste.httpserver - paste is a huge package with other stuff in it
  5. flup - same as paste, too much stuff.
  6. Spawning - never used it but seems lightweight enough.
  7. Tornado - not really wsgi + full "framework"
  8. Werkzeug - runcommand

any others out there? which one you prefer?

+4  A: 

One you might want to look at is Werkzeug - it is a WSGI utility toolkit. It includes a runserver function that takes the wsgiref server and adds automatic code reloading (you can also configure it to reload when configuration files change) and an awesome debugger.

On a side note, your disdain for frameworks makes it sound like you're planning to handle all the WSGI stuff from scratch, in which case I would recommend you use Werkzeug's utility functions to handle parsing requests and generating responses. It's a lot more fun than doing it yourself. (And for the love of Guido, PLEASE don't use cgi.FieldStorage!)

LeafStorm
I have nothing agains frameworks. In fact I'm a big contributor to TurboGears that said you need to use the right tool for the job and in this case getting paste installed seems like a huge package just for testing.
Jorge Vargas
Okay, I guess I just misinterpreted your phrasing. Sorry about that.
LeafStorm
A: 

So far I've been using CherryPy, and compared to Django (which, while not in your list, is the only other dev server I used) I like it heaps more. It does what is says: it is only there when you need it, and gets out of the way for the rest of the time.

Using Django seemed like I needed to subscribe to the Django way of doing things. Although Django provides heaps more functionality out of the box (default admin interface, widgets on your webpages) , using CherryPy seems like just another import that has very good (often surprising you with extra) functionality.

Alex Boschmans
if you like the cherrypy one then you will love WebError. That said it seems you are mixing "web framework" with "web server".
Jorge Vargas
+1  A: 

I'd recommend paste or CherryPy. They're the easiest to get up and running with.

Jason Baker
A: 

One really easy way is CGI (together with a regular web server, and using wsgiref.handlers.CGIHandler). Terrible for performance on a production server, but great for development. You can write a single script that works as both a mod_wsgi WSGIScriptAlias (exposing an application object), and as a mod_cgi ScriptAlias (calling wsgiref when __name__=='__main__').

Many WSGI environments have a way to reload the basic script, for example mod_wsgi's WSGIScriptReloading, which is on by default. Unfortunately, you're likely to be putting much of your code in modules, which isn't so easy to reload. In mod_wsgi you can also do it by sending a SIGINT to perform a reload when in daemon mode. Unfortunately you still have to sniff every module you're using for mtime updates in order to know whether you have to reload. And it doesn't work in embedded mode.

A messy but feasible approach is to sniff all modules that are part of your application, and if any have been updated since the last check, reload them all. You have to reload them at once, by removing them all from the sys.modules lookup (remove None-valued entries too whilst you're there, to avoid relative import lookup problems), in order to ensure they don't keep cross-references to the old versions of themselves. And of course they must not leave other references to themselves outside of your application. You can see an example of this in action in the ModuleUpdater class here.

(This software isn't ready for release, but has been providing module reloading for my WSGI apps for a few years and seems to be stable. The idea is to put all your WSGI app in an application class in a package, which you can import from a single WSGI/CGI/command-line entry point script; you include the deployment config in that script.)

bobince
It seems like you are reinventing what all of the above modules do, for example Spawning implements your algorithm for code reload. That said I'm not looking to start yet another implementation.
Jorge Vargas
Not exactly reinventing; I've been using this longer than Spawning has existed! The difference from others that I know of is that WSGI deployment is pretty much all this module does; it doesn't drag a server or app framework into the equation.
bobince
I don't want to pick a fight but paste.reloader is even older than Spawning. My original point is that you point to your code which isn't officially released in pypi, you say it's stable yet you don't stand behind that (or so it seems)
Jorge Vargas
I'm pointing at it as example code of a working approach to code reloading without framework baggage, not suggesting that people deploy it now.
bobince
+2  A: 

Check out run_simple from werkzeug:

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

In addition to giving you automatic code reloading, you can use use_debugger=True to include their pretty spiffy debugger on top of your app (which includes console in each line of the traceback).

Mark Hildreth
A: 

You can use paste.reloader with any wsgi-server, aside of other paste modules.

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

Is that minimalistic enough?

A: 

Also, you missed web.py, which is both small and supports code reload.