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". _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com