[Web-SIG] Entry points and import maps (was Re: Scarecrow deployment config
Chris McDonough
chrism at plope.com
Mon Jul 25 09:02:27 CEST 2005
Actually, let me give this a shot.
We package up an egg called helloworld.egg. It happens to contain
something that can be used as a WSGI component. Let's say it's a WSGI
application that always returns 'Hello World'. And let's say it also
contains middleware that lowercases anything that passes through before
it's returned.
The implementations of these components could be as follows:
class HelloWorld:
def __init__(self, app, **kw):
pass # nothing to configure
def __call__(self, environ, start_response):
start_response('200 OK', [])
return ['Hello World']
class Lowercaser:
def __init__(self, app, **kw):
self.app = app
# nothing else to configure
def __call__(self, environ, start_response):
for chunk in self.app(environ, start_response):
yield chunk.lower()
An import map would ship inside of the egg-info dir:
[wsgi.app_factories]
helloworld = helloworld:HelloWorld
lowercaser = helloworld:Lowercaser
So we install the egg and this does nothing except allow it to be used
from within Python.
But when we create a "deployment descriptor" like so in a text editor:
[helloworld from helloworld]
[lowercaser from helloworld]
... and run some "starter" script that parses that as a pipeline,
creates the two instances, wires them together, and we get a running
pipeline?
Am I on track?
OK, back to Battlestar Galactica ;-)
On Mon, 2005-07-25 at 02:40 -0400, Chris McDonough wrote:
> BTW, a simple example that includes proposed solutions for all of these
> requirements would go a long way towards helping me (and maybe others)
> understand how all the pieces fit together. Maybe something like:
>
> - Define two simple WSGI components: a WSGI middleware and a WSGI
> application.
>
> - Describe how to package each as an indpendent egg.
>
> - Describe how to configure an instance of the application.
>
> - Describe how to configure an instance of the middleware
>
> - Describe how to string them together into a pipeline.
>
> - C
>
>
> On Mon, 2005-07-25 at 02:33 -0400, Chris McDonough wrote:
> > Thanks...
> >
> > I'm still confused about high level requirements so please try to be
> > patient with me as I try get back on track.
> >
> > These are the requirements as I understand them:
> >
> > 1. We want to be able to distribute WSGI applications and middleware
> > (presumably in a format supported by setuptools).
> >
> > 3. We want to be able to configure a WSGI application in order
> > to create an application instance.
> >
> > 2. We want a way to combine configured instances of those
> > applications into pipelines and start an "instance" of a pipeline.
> >
> > Are these requirements the ones being discussed? If so, which of the
> > config file formats we've been discussing matches which requirement?
> >
> > Thanks,
> >
> > - C
> >
> > On Sun, 2005-07-24 at 22:24 -0400, Phillip J. Eby wrote:
> > > At 08:35 PM 7/24/2005 -0400, Chris McDonough wrote:
> > > >Sorry, I think I may have lost track of where we were going wrt the
> > > >deployment spec. Specifically, I don't know how we got to using eggs
> > > >(which I'd really like to, BTW, they're awesome conceptually!) from
> > > >where we were in the discussion about configuring a WSGI pipeline. What
> > > >is a "feature"? What is an "import map"? "Entry point"? Should I just
> > > >get more familiar with eggs to understand what's being discussed here or
> > > >did I miss a few posts?
> > >
> > > I suggest this post as the shortest architectural introduction to the whole
> > > egg thang:
> > >
> > > http://mail.python.org/pipermail/distutils-sig/2005-June/004652.html
> > >
> > > It explains pretty much all of the terminology I'm currently using, except
> > > for the new terms invented today...
> > >
> > > Entry points are a new concept, invented today by Ian and myself. Ian
> > > proposed having a mapping file (which I dubbed an "import map") included in
> > > an egg's metadata, and then referring to named entries from a pipeline
> > > descriptor, so that you don't have to know or care about the exact name to
> > > import. The application or middleware factory name would be looked up in
> > > the egg's import map in order to find the actual factory object.
> > >
> > > I took Ian's proposal and did two things:
> > >
> > > 1) Generalized the idea to a concept of "entry points". An entry point is
> > > a name that corresponds to an import specification, and an optional list of
> > > "extras" (see terminology link above) that the entry point may
> > > require. Entry point names exist in a namespace called an "entry point
> > > group", and I implied that the WSGI deployment spec would define two such
> > > groups: wsgi.applications and wsgi.middleware, but a vast number of other
> > > possibilities for entry points and groups exist. In fact, I went ahead and
> > > implemented them in setuptools today, and realized I could use them to
> > > register setup commands with setuptools, making it extensible by any
> > > project that registers entry points in a 'distutils.commands' group.
> > >
> > > 2) I then proposed that we extend our deployment descriptor (.wsgi file)
> > > syntax so that you can do things like:
> > >
> > > [foo from SomeProject]
> > > # configuration here
> > >
> > > What this does is tell the WSGI deployment API to look up the "foo" entry
> > > point in either the wsgi.middleware or wsgi.applications entry point group
> > > for the named project, according to whether it's the last item in the .wsgi
> > > file. It then invokes the factory as before, with the configuration values
> > > as keyword arguments.
> > >
> > > This proposal is of course an *extension*; it should still be possible to
> > > use regular dotted names as section headings, if you haven't yet drunk the
> > > setuptools kool-aid. But, it makes for interesting possibilities because
> > > we could now have a tool that reads a WSGI deployment descriptor and runs
> > > easy_install to find and download the right projects. So, you could
> > > potentially just write up a descriptor that lists what you want and the
> > > server could install it, although I think I personally would want to run a
> > > tool explicitly; maybe I'll eventually add a --wsgi=FILENAME option to
> > > EasyInstall that would tell it to find out what to install from a WSGI
> > > deployment descriptor.
> > >
> > > That would actually be pretty cool, when you realize it means that all you
> > > have to do to get an app deployed across a bunch of web servers is to copy
> > > the deployment descriptor and tell 'em to install stuff. You can always
> > > create an NFS-mounted cache directory where you put pre-built eggs, and
> > > EasyInstall would just fetch and extract them in that case.
> > >
> > > Whew. Almost makes me wish I was back in my web apps shop, where this kind
> > > of thing would've been *really* useful to have.
> > >
> >
> > _______________________________________________
> > Web-SIG mailing list
> > Web-SIG at python.org
> > Web SIG: http://www.python.org/sigs/web-sig
> > Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com
> >
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com
>
More information about the Web-SIG
mailing list