[Distutils] [Web-SIG] Entry points and import maps (was Re: Scarecrow deployment config
Phillip J. Eby
pje at telecommunity.com
Mon Jul 25 01:20:20 CEST 2005
At 02:12 PM 7/24/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>However, after more thought, I think that the "next application" argument
>>should be a keyword argument too, like 'wsgi_next' or some such. This
>>would allow a factory to have required arguments in its signature, e.g.:
>> def some_factory(required_arg_x, required_arg_y, optional_arg="foo",
>> ....):
>> ...
>>The problem with my original idea to have the "next app" be a positional
>>argument is that it would prevent non-middleware applications from having
>>any required arguments.
>
>I think it's fine to declare the next_app keyword argument as special, and
>promise (by convention) to always pass it in with that name.
Actually, now that we have the "entry points" capability in pkg_resources
(I just checked it in), we could simply have middleware components looked
up in 'wsgi.middleware_factories' and applications looked up in
'wsgi.application_factories'. If a factory can be used for both, you can
always list it in both places.
Entry points have 1001 uses... I can imagine applications defining entry
point groups for URL namespaces. For example, Trac has URLs like
/changesets and /roadmap, and these could be defined via a trac.navigation
entry point group, e.g.:
[trac.navigation]
changesets = some.module:foo
roadmap = other.module:bar
And then people could easily create plugin projects that add additional
navigation components. (Trac already has an internal extension point
system to do things rather like this, but entry points are automatically
discoverable without any prior knowledge of what modules to import.)
There are other frameworks out there (e.g. PyBlosxom), both web and
non-web, that could really do nicely with having a standard way to do this
kind of thing, rather than having to roll their own.
More information about the Distutils-SIG
mailing list