[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