[Web-SIG] WSGI and Configuration

[Alan Kennedy]

[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 
good second-best.

 > 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.

+0

 > But first, I'd like to finalize PEP 333.  :)

+1

 > 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.

+1

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 
week.

regards,

Alan.