[Web-SIG] WSGI and Configuration

[Phillip J. Eby]

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', 
>os.environ.get('ZOPE_SITE_CONF')).

Yep.


>>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 
nice?)

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 
>>configuration caching.
>
>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 
per stack.

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.