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

[Phillip J. Eby]

At 08:49 PM 7/24/2005 -0500, Ian Bicking wrote:
>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?
>
>It wouldn't hurt to read up on eggs.  It's not obvious how they fit here, 
>and it's taken me a while to figure it out.  But specifically:
>
>* Eggs are packages.  Packages can have optional features.

I've taken to using the term "project" to mean a collection of packages, 
scripts, data files, etc., wrapped with a setup script.  In order to avoid 
confusion with other kinds of "features" and "options", the official term 
for those things is now "extras".  An "extra" is some optional capability 
of a project that may incur additional requirements.


>   Those features can have additional requirements (external packages) 
> that the base package does not have.  Package specifications are spelled 
> like "PackageName>=VERSION_NUMBER[FeatureName]"

Actually, it's "ProjectName[extra,...]>=version", and you can list multiple 
version operators, like "FooBar>1.2,<2.1,==2.6,>3.0" to mean versions 
between 1.2 and 2.1 exclusive, and anything *after* 3.0, but 2.6 was okay 
too.  :)

I'm proposing that for WSGI entry points, we allow everything but the 
[extras_list] in a section heading, e.g.:

     [wiki from FooBarWiki>=2.0]

would mean what it looks like it does.  By the way, all this version 
parsing, dependency checking, PyPI-finding, auto-download and build from 
source or binary stuff already exists; it's not a hypothetical 
pie-in-the-sky proposal.


>* Import maps and entry points are new things we're discussing now. They 
>are kind of the same thing; basically an entry point maps a logical 
>specification (like a 'wsgi.app_factory' named 'foo') to a actual import 
>statement.  That's the configuration file:
>
>   [wsgi.app_factory]
>   app = mymodule.wsgi:make_app
>
>Which means to get an object "app" which fulfills the spec 
>"wsgi.app_factory" you would do "from mymodule.wsgi import make_app"
>
>Eggs have an PackageName.egg-info directory, where configuration files can 
>go, and pkg_resources (which is part of setuptools, and associated with 
>easy_install, and defines the require() function) can find and parse them.

Yes, and with the CVS HEAD version of setuptools you can now specify a 
project's entry point map in it setup script, and it will generate the 
entry point file in the project's .egg-info directory, and parse it at 
runtime when you request lookup of an entry point.  There's an API in 
pkg_resources that lets you do:

     factory = load_entry_point("ProjectName", "wsgi.app_factory", "app")

which will do the same as if you had said "from mymodule.wsgi import 
make_app as factory".