[Web-SIG] PasteDeploy comments

[Ian Bicking]

Jim Fulton wrote:
> 
> On Mar 2, 2007, at 8:17 PM, Ian Bicking wrote:
> 
>> Jim Fulton wrote:
>>>   What have you used global configuration data for?
>>
>> It's often meant for configuration that applies to many components.  
>> For instance, a "debug" value that applies widely (or could also be 
>> applied locally).  Or information about where to email errors, some 
>> logging information, etc.  E.g., you might give a base directory for 
>> logging in global_conf, and an application could pick that up and 
>> probably put it in a subdirectory there (where if you configured it 
>> locally, you'd probably give the application the full path of the log 
>> file).
> 
> I know what it's meant for.  I was asking what it was actually *used* 
> for.  Is this truly useful?

Well, for some things like the debug setting, definitely.  That is, 
*some* applications consume that value, but not all, and in the form of 
global_conf the value just sort of hangs out without being applied to 
anything in particular.  In deployments where I'm using a set of 
applications designed to work together I've found it useful to pass 
values to all of the applications at once.  Also when you pass values in 
through the command-line it gets put into global_conf, because it's not 
clear what section it would otherwise apply to (since the application 
you are intending to effect may be wrapped by middleware).

>>   Also, it seems like there should be a better way to shut it down 
>> than killing the entire process.  For instance, for performance testing.
> 
> <shrug>  This doesn't seem important to me.

Really what I'd like it for is testing, in those times when I really 
want to start up a real HTTP server to test against, then cleanly shut 
it down.

>>> Overall, PasteDeploy looks very usable.  I'll probably find other 
>>> issues when I actually try to use it.  One of my next projects wil be 
>>> to look at how to use it in Zope.  zope.paste is a bit too much of a 
>>> wedge.
>>
>> zope.paste, as I remembered it, didn't really seem to allow things 
>> like instantiating multiple Zope applications.  But I can't remember.  
>> And that's not always feasible; Zope 2 is unlikely to really support 
>> many truly separate instantiated applications, but it could still 
>> support the basic configuration.
> 
> zope.paste tries very hard to minimize its impact on zope 
> configuration.  It has to make a number of compromises to do this.  It 
> is impossible to run "truly separate" Python applications in the same 
> process, for some definition of "truly separate" and "application".  
> separate WSGI applications will share common module definitions and 
> shared module globals.  I can easily imagine separate Zope (2 & 3) 
> applications that exposed separate object spaces or sets of procedural 
> (as opposed to object-based) pages.

"Separate" instances of applications is a fairly vague notion, that only 
means something when applied specifically.  I would hope that you could 
start two Zope apps pointing at different ZODB instances, just like you 
should be able to start two apps pointing to different objects in the 
same ZODB.

>>> On a related note, I'll probably want to do process configuration in 
>>> the same file that that PasteDeploy uses. This would likely include 
>>> things like:
>>> - interrupt-check-interval
>>> - Log files
>>> I guess there is nothing to prevent this.  I suspect that I'll also 
>>> get a lot of resistence to moving this out of zope.conf. :/
>>
>> Yes, the container configuration.  (Incidentally, what exactly do we 
>> call this thing we're proposing to make?)
> 
> I'm not sure we're initially proposing to make *a* thing. For starters I 
> think we're exploring using the PasteDeploy-defined frameworks and to 
> collaborate on sever testing.
> 
> I would call this the main program, but maybe other terms would be better.
> 
>>> Have you tried pointing logging.fileConfig at a cnfig file containing 
>>> PasteDeplot sections?  I assume it would work.
>>
>> I haven't tried it, but I think Ben Bangert has started work on that, 
>> using global_conf['__file__'] that way.  A more cohesive logging story 
>> that included that would be nice.
> 
> I think this should be done by the main program (container/whatever) not 
> by an application.

In the case of Paste and Pylons, we wanted to add a bunch of logging to 
the library.  The library at that point doesn't belong to any 
application.  Having a bunch of logging without a clear story about how 
to use that logging seemed bad (in this case it's mostly logging 
intended for programmers, not final deployment, but some portions could 
be useful in final deployment).

It could (and probably would) be applied as an outer middleware applied 
by individual applications, but ideally there would be shared 
conventions across frameworks.  Ideally it would also make 
application-specific logging easier.  I think logging configuration is a 
general use case we should consider, but I don't think it's part of the 
container really.  It might relate to something in Paste Deploy 
configuration.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org