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

Phillip J. Eby pje at telecommunity.com
Mon Jul 25 05:06:32 CEST 2005


At 09:33 PM 7/24/2005 -0500, Ian Bicking wrote:
>We could go free-form, and you call application factories with keyword
>arguments that are dependent on the application.  This serves as
>configuration.  You can call filter factories with keyword arguments,
>and one special (required?) keyword argument "next_app".

I think we can just go positional on the next-app argument, since only 
filter factories can do anything with it.


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


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


>   This way a function in paste (or wherever)
>could serve as the loader for any application with the proper
>framework-specific metadata (and so probably this could devolve into
>per-framework loaders).

I don't understand.


>   This would perhaps preclude non-setuptools
>factories, though you could also pass in None for the distribution for
>those cases.

Huh?

I propose that we allow import specs as factory designators, so that the 
default case works fine without setuptools.  You only need setuptools if 
you use factory specs of the form "[feature from Project...]".  Of course, 
they're so cool that everybody will *want* to use them...  ;)



More information about the Web-SIG mailing list