[Web-SIG] Entry points and import maps (was Re: Scarecrow deployment config
chrism at plope.com
Mon Jul 25 08:33:43 CEST 2005
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?
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:
> 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.
More information about the Web-SIG