[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
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
I don't understand.
> This would perhaps preclude non-setuptools
>factories, though you could also pass in None for the distribution for
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