[Web-SIG] Entry points and import maps (was Re: Scarecrow deployment config

Phillip J. Eby pje at telecommunity.com
Mon Jul 25 04:24:28 CEST 2005


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.



More information about the Web-SIG mailing list