[Web-SIG] Entry points and import maps (was Re: Scarecrow deployment config
Phillip J. Eby
pje at telecommunity.com
Mon Jul 25 04:33:31 CEST 2005
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
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
>* 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:
> 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".
More information about the Web-SIG