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