Sune Kirkeby wrote:
On 10/11/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
* 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.
Definetly. And with #584 it would be a lot closer to Just Working(tm).
Django should also load SQL-scripts from Eggs when installing applications,
but that's all I can see missing.
One thing I've considered with deployment is Yet Another Entry Point, an
on-app-installation entry point. It's important to distinguish between
installing the app's code and installing an app instance. Installing
the code just means running easy_install, and should only make the app
available on the system, it doesn't enable it anywhere.
* easy to build a WSGI app
It is.
import django.core.handlers.wsgi
app = django.core.handlers.wsgi.WSGIHandler()
Because of the magic Django does with settings, there can only ever
be one instance per Python process... Unless I'm missing something.
That would be somewhat of a problem, because you couldn't install two
Django apps in the same process without them being aware of each other,
so in effect they won't be encapsulated. CherryPy has the same problem,
with the handler being mostly fixed. In Django's case, it seems like if
you could just pass some identifier into WSGIHandler then you'd be able
to specify which app you want to run.
One way to handle the configuration issue is with a wrapper around the
WSGI app that sets up the environment on an incoming request, and then
tears it down on the way out. paste.deploy.config does this:
http://svn.pythonpaste.org/Paste/Deploy/trunk/paste/deploy/config.py
In that code, DispatchingConfig (instantiated as CONFIG) uses
threadlocal storage so that you can import "the" configuration at the
module level, but its keys are based on whatever the current request is.
Then ConfigMiddleware sets up the configuration on incoming requests,
and tears it down when the request is finished.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
