Hello Djangoists. Ben Bangert mentioned that he was having some conversations with Adrian about Paste and "Paste Enabling" Django. I haven't written up my Paste Enabling Propoganda yet, but I'll just say that I *will* write up propoganda ;)
Anyway, I thought I'd describe what I think it might mean in the context of Django, just to get the discussion started. Sadly I won't be able to follow up on the discussion much, as I'll be out of contact from the 13th to the 21st. Anyway, for something to be Paste Enabled it should be: * easily installable. easy_install being a good way to do that. This means each app goes in its own package with a setup.py file. This isn't absolutely necessary, but packaging each app is generally good for deployment. * easy to build a WSGI app So... you guys can think about the installable part as well as I can. The important part is to keep application "instance" data out of the code. Which means keeping configuration out of the code. You might want to look at this code too for generating package_data, as that's otherwise a pain: http://svn.pythonpaste.org/Paste/trunk/paste/util/finddata.py Anyway, on to the second part. Paste Deploy is basically a way of reading configuration files and calling a function based on that. The specifics are on the page: http://pythonpaste.org/deploy/ In general it means you have a named "entry point" (something Eggs/setuptools provides) that points to a specific function. An expedient way to do this with current Django layouts might be like: # this describes one app: [app:main] use = egg:Django#from_module module = myapp.module.name That is, Django itself provides an entry point "from_module" ("main" is the default entry point). In setup.py that looks like: setup(... entry_points=""" [paste.app_factory] from_module = django.wsgibuilder:from_module """) So in the django.wsgibuilder module you have a function like: def from_module(global_conf, module, other settings...): # "module" and all other settings will be strings and that returns a WSGI application. global_conf is a dictionary of settings that are meant to apply to all applications (potentially) and can be fallback settings. Another option instead of using the paste configuration file for your settings, you could use another configuration value that points to a module or file that contains your configuration, which could be used to load the configuration files as they are being used now. So... now that you've gotten that far paste.deploy.loadapp('config:filename') will load the WSGI application. "paster serve filename" uses that function to run an application server; you can use that, or whatever -- once you have the WSGI app it's pretty easy to do whatever you want with it. One thing Paste also provides is some applications to make it easy to run multiple apps in the same process, dispatching as necessary. This is similar to what Django already does; depending on how you want to compose applications you can use that or implement something similar that uses Django's techniques for URL dispatching. The basic model right now is: [composit:main] use = egg:Paste#urlmap / = root /new = news /blog = config:blog.ini [app:root] ... and also for app:news, and another app described in blog.ini So the "urlmap" entry point in Paste uses the configuration to dispatch to other named applications. It's not a particularly fancy or (I think) scary function, so it's something to think about. Anyway, put together I think this creates a pretty good deployment scenario, and one that's going to be seeing more improvements over time. The ideal is: paster deploy EasyInstallableAppName deployment config vars... Which, based on some configuration file about how you deploy on this computer, will install the app (possibly from a private repository), write out a configuration file, and put it in place, and run any custom post-install scripts. And that's not too far off. Ian
