[Zope-dev] zope.container analysis

[Martijn Faassen]

Hey,

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 
zope.interface).

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:

http://startifact.com/depgraphs/zope.container.svg

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

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?

Regards,

Martijn