[Web-SIG] WSGI deployment part 2: factory API

[Phillip J. Eby]

At 10:26 PM 7/24/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>Another option is we pass in a single dictionary that represents the
>>>entire configuration.  This leaves room to add more arguments later,
>>>where if we use keyword arguments for configuration then there's really
>>>no room at all (the entire signature of the factory is taken up by
>>>application-specific configuration).
>>
>>YAGNI; We don't have any place for this theoretical extra configuration 
>>to come from, and no use cases that can't be met by just adding it to the 
>>configuration.  Early error trapping is important, so I think it's better 
>>to let factories use normal Python argument validation to have required 
>>arguments, optional values, and to reject unrecognized arguments.
>
>I think in practice I'll always take **kw, because I otherwise I'd have to 
>enumerate all the configuration all the middleware takes, and that's 
>impractical.  I suppose I could later assemble the middleware, determine 
>what configuration the actual set of middleware+application takes, then 
>check for extras.  But I doubt I will.  And even if I do, it's incidental 
>-- I'm quite sure I won't use using the function signature for parameter 
>checking.

Well, I'm sure I will for simple things.  For more complex things, I'll use 
the pattern of checking **kw against class attributes to make sure they 
exist.  PEAK, for example, already has this ability built-in, so it's 
definitely the path of least resistance for implementing a middleware 
component in PEAK; just subclass binding.Component and add attribute 
bindings for everything needed.  I'd hate to give that up for a theoretical 
argument that someday we might need some kind of arguments that aren't 
arguments.  It's not as if we couldn't define a new protocol, and a 
different modifier in the deployment descriptor, if that day ever actually 
arrived.


>>>Another part of the API that I can see as useful is passing in the
>>>distribution object itself.
>>
>>Which distribution?  The one the entry point came from?  It already knows 
>>(or can find out) what distribution it's in.
>
>I mean like:
>
>   [wsgi.app_factory]
>   filebrowser = paste.wareweb:make_app
>
>Where paste.wareweb.make_app knows how to build an application from 
>filename conventions in the package itself, even though the paste.wareweb 
>module isn't in the project itself.

Oh.  I think I get you now; you want to be able to define an entry point 
that wraps itself in something else.  I don't see though why I can't just 
put the wrapper code in myself, like this:

     def my_app(*args, **kw):
         return paste.wareweb.make_app(
             pkg_resources.get_provider(__name__), *args, **kw
         )

And then just make the entry point refer to this.  Or, if you want to be fancy:

     my_app = paste.wareweb.app_maker(__name__)

This seems more than sufficient for the use case.