[Web-SIG] WSGI and Configuration
Phillip J. Eby
pje at telecommunity.com
Sat Nov 13 03:55:29 CET 2004
At 11:52 PM 11/12/04 -0600, Ian Bicking wrote:
>I can certainly see that need as well, though you can kind of do that in
>an ad hoc way, with stuff like environ.get('ZOPE_SITE_CONF',
>>Actually, I think there are now starting to be enough deployment examples
>>to maybe add a "Deployment Recommendations" section to the PEP. It seems
>>to me that the best practice at this point is:
>>* Application developer should supply their application as an importable
>>object, and specify what configuration variables it requires.
>Sounds good. "Importable" is a pain. I think most web frameworks have to
>deal with the annoyances of importing arbitrary files, which is crufy in
>Python and has all sorts of annoying corner cases. Maybe we can solve
>that more cleanly while we're at it? Maybe as part of wsgiref, maybe
>pulling out the importing stuff you have in PEAK.
>wsgikit.urlparser.load_module has one implementation, but I know it's
>sub-optimal. In some models of URL resolution, like Apache, there's no
>relation of files to sys.path or any importable name. Webware just
>creates fake names in that case. In any case relative imports are all
>funky. Anyway, I'd love to have a solid solution to those issues. But
>that's kind of an aside.
*Shudder*. Ideally, a server would allow customizing sys.path at least
long enough to import/setup the application. Otherwise, we lose out on
being able to e.g. deploy an application in a zipfile. (Wouldn't that be
I don't think PEAK's import tools really have much to offer here, unless
you just mean the convenient 'importString()' function. Couple that with
maybe some temporary additions to sys.path, and you're set.
Of course, of the Python web servers out there, I'm thinking only
mod_python and modjy are really going to be able to handle this
well. mod_python can run apps in separate interpreters, and each can have
its own, completely transparent sys.path. modjy uses Jython, so in
principle it could run apps in different interpreters, though I don't think
it currently does.
I *do* have a project on the back burner to make the CPython
multi-interpreter API accessible from Python code, though. Indeed, I
intend to write a PEP to propose standardizing a multi-interpreter API
for CPython, Jython, IronPython, and indeed all Python
implementations. But first, I'd like to finalize PEP 333. :)
>>Alternatively, I wonder if perhaps there should be an "application setup"
>>importable, that gets passed the configuration, and returns the
>>application? This would be useful for applications that want to do some
>>initial setup, and don't want to have to write a bunch of code to manage
>In this case, I think the person can create a script that invokes both
>server and sets up the application. I guess.
>I'm actively changing my mind on what I want, so if I'm inconsistent...
I noticed that. :) Anyway, the "app setup" idea was to get things to the
point that, in principle, the user would only have to edit configuration
files to deploy a WSGI application. They shouldn't have to write scripts
just to run an application. Even for middleware stack management, if each
piece of middleware had a configuration variable to specify what its
downstream app-setup call was, you could create the whole thing from server
config, as long as you had only one instance of a given kind of middleware
Anyway, in an ideal world, you shouldn't have to edit the application
itself, only its config file(s). And the application should find out its
config file(s) from the server. Then, the application code is reusable to
deploy multiple copies of the app. If you can't do that, then the user has
to write a script for each deployed instance.
More information about the Web-SIG