[Zope-dev] zope.container analysis
faassen at startifact.com
Fri May 15 07:17:54 EDT 2009
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
> - 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?
More information about the Zope-Dev