In discussing dependencies, as we try to clean up dependencies of Zope
(especially ZTK) projects, I've noticed a pattern that I think
deserves some special handling.

Often, a module (including a ZCML file) within a project provides an
implementation of an interface defined by an external package or an
adapter of a class or interface defined in the external package.  If
the module is optional and exists solely to integrate with the
external API, then the external project need not be a dependency. Why?
Because an application won't use this module unless it already uses
the external project.

For example, lots of projects provide publisher views or zcml
configuration directives.  As long as these are in optional modules or
ZCML files, then dependencies on zope.publisher or zope.configuration
aren't necessary, as no one will use these modules or zcml files
unless they're already using zope.publisher or zope.configuration.
Again, this assumes that these modules are optional.  For example, if
a project's configuration file, configure.zcml registers views or
includes a configuration file that registers views, then the
dependency on zope.publisher is not optional.

Let's look at a more specific example. provides
some xmlrpc view registrations for zope.container in
xmlrpc/configure.zcml.  If the xmlrpc module was optional, or if these
container registrations were conditedl [1]_ on zope.container having
been installed, then wouldn't need to depend on
zope.container [2]_.  As it stands though, one can't include the main
configuration for without also configuring the
container xmlrpc views, so zope.container is required.


.. [1] We can make these registrations conditional on zope.container like this:

  <configure condition="installed zope.container" >

.. [2] This assumes we could get rid of the zope.container import in
        browser/tests/test_directoryresource, which I strongly suspect
        we can.)

Jim Fulton
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to