Chris McDonough wrote:
> zope.container (32 transitive dependencies) has some possibly low-hanging 
> dependency  tease-apart fruit.  Does anyone have any ideas about to sort out 
> the 
> below, particularly with externalizing the mentioned interface dependencies?
> - It depends on zope.filerepresentation but depends only on its interfaces
>    IReadDirectory, IWriteDirectory, and IDirectoryFactory.
>    (zope.filerepresentation has 32 transitive dependencies).

Heh, zope.filerepresentation has 32 transitive dependencies because 
they're zope.container's. :) (the only other dependency is has it 

There's a simple cycle from filerepresentation to container and back. 
When we looked at them last it's not clear how to resolve them cleanly. 
Suggestions from anyone?

Anyway, this cycle isn't a dramatic one as it only keeps this one 
package alive.

> - It depends on zope.app.dependable but depends only on its interfaces
>    IDependable and DependencyError.  (note: zope.app.dependable might
>    be a candidate to be called zope.dependable as it depends on no other 
> zope.app
>    packages; it does depend on about 20 other zope.* packages transitively 
> tho).

Looking at the graph here:


It looks like zope.app.dependable most depends directly on things 
zope.container depends on through other routes anyway. The exception is 

I see you removed the dependency on zope.app.dependable partially by 
making it conditional. That looks reasonable and should cut out 
zope.annotation as well.

> - It depends on zope.publisher, but only its interfaces 
> browser.IBrowserRequest,
>    browser.IBrowserPublisher, NotFound, IDefaultViewName,
>    xmlrpc.IXMLRPCPublisher, and IPublishTraverse.
> - I was able to break a runtime logic dependency on zope.traversing by
>    disusing zope.traversing.api.getPath in favor of using
>    ILocationInfo(object).getPath().  The rest of the runtime dependencies on
>    zope.traversing are interface dependencies (ITraversable, 
> IContainmentRoot).

It's tempting to start pushing more interfaces (and exceptions) down 
into zope.browser to break dependencies further. It does run the risk of 
turning zope.browser into a bit of a mash though. Perhaps that's worth 
it. Opinions, anyone?



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to