[Web-SIG] WSGI and Configuration
py-web-sig at xhaus.com
Sat Nov 13 16:28:38 CET 2004
[Phillip J. Eby]
> *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 nice?)
Very nice. It would be great to just drop a zipfile containing all code
and support resources into a single configured location, j2ee-war-style.
This would be a *huge* boon to simplifying deployment. WSGI presents
many opportunities for simplifying server admin, and IMHO we should take
advantage of as many as possible.
> 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.
Currently modjy doesn't support multiple interpreters, since I recoded
it in jython for prototyping simplicity. When I port (some of) it back
to java, it is straightforward to support multiple interpreters.
At the moment, due to time constraints on my part, modjy is basically in
"follow mode": i.e. I will implement extras for it as and when clear
concensus emerges on issues.
But I can already see that modjy's naive import mechanism is soon going
to become a hindrance. I'd really appreciate some pointers to clear
guidance/reading-material on the full range of issues that can arise
with imports, if anyone knows of such? Pointers to good (i.e. well
structured and well documented) code that handles imports would be a
> 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. :)
> 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.
IMO, we should strive for that ideal world, because we can. We have a
golden opportunity, right here, right now: the python world is watching
WSGI, and the python world seems to be growing larger and larger by the
More information about the Web-SIG