Zope Configuration Egg Support
Status: IsRetractedProposal in favor of ZIPImportSupportForZope3
Author
Problem
We are making increasing use of Python eggs for Zope development. We need to be able to load ZCML from eggs.
Proposal
I propose to add an egg attribute to the ZCML include directive. The egg attribute would function like the package attribute. A file attribute can be used to name a file within the egg and will default to configure.zcml. It would be illegal to use the egg and package attributes together.
I also propose to add an entry-point attribute which will name an entry point within the zope.configuration group. The entry point will name a Python callable that will be called with a configuration context. The callable will then generate actions by calling the action method on the context. Of course, this introduces the ability to define configuration in Python. :) More will be said about Python configuration support in a separate proposal.
Because eggs are not hierarchical, there can be no relative egg references.
We will add an API to configuration contexts access files. This is necessary because pkg_resource APIs? will need to be used when accessing files from zipped eggs. Existing directives that access files will need to be changed to use this API.
Risks
Directives that attempt to access files, such as templates or static resources will not work correctly unless they are modified to work with the new context API.
Implementation Status
NotImplemented?
... --TresSeaver?, Mon, 23 Oct 2006 05:12:11 -0700 reply
We might also synthesize entry points for ZCML files in eggs, so that "introspective" tools could
query eggs for their configuration sets. Configurations created in Python (blech) would then
be queried in the same way as those created in ZCML.
... --Ian Bicking, Mon, 23 Oct 2006 10:38:58 -0700 reply
Some of the configuration could be handled, perhaps, by defining an entry point of a module that should be eagerly imported. For instance, an adapter can register itself in Python code already, it simply needs to be imported to do so.
This could be defined like:
[zope.adapters] mypackage.IFoo to zope.IView = mypackage.ifooadapter
In this model the adapter name defines the adaptation that is available. Multiple entry points could point to the same module, if that module had multiple adapters. A simpler way would simply be:
[zope.registrations] myview = mypackage.ifooadapter mywhatever = mypackage.interfaces
And all of these modules would be loaded as soon as the egg was activated (for whatever that means - probably something like package-includes). The entry point name wouldn't be meaningful, it just has to be unique for every entry point. The modules would then register themselves at import time.
(Is the retraction for zip import backwards? Using the pkg_resources resource API should solve the zip import problem, even for non-eggs)
