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

[Chris McDonough]

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
>