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

[Chris McDonough]

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.
>