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). - 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). - 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).
On 5/14/09 11:05 PM, 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).
I found out that zope.container<->zope.filerepresentation is a direct circular dependency and that zope.filerepresentation is a package containing only interfaces. So breaking this dependency won't get us much for zope.container. OTOH, breaking zope.filerepresentation's dependency on zope.container might be a win (I dont know what else depends on zope.filerepresentation). zope.filerepresentation depends only on zope.container.interfaces.IReadContainer and zope.container.interfaces.IWriteContainer.
- 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).
I fixed this by using a zcml:condition statement on an event subscriber.. if zope.app.dependable is not installed, nothing could have been registered for the IDependable interface which a "CheckDependency" subscriber is using to figure out dependents, so there's no use registering the subscriber.
- 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).
These are still up for debate. - C
Chris McDonough wrote:
On 5/14/09 11:05 PM, Chris McDonough wrote:
- It depends on zope.filerepresentation but depends only on its interfaces IReadDirectory, IWriteDirectory, and IDirectoryFactory. (zope.filerepresentation has 32 transitive dependencies).
I found out that zope.container<->zope.filerepresentation is a direct circular dependency and that zope.filerepresentation is a package containing only interfaces. So breaking this dependency won't get us much for zope.container. OTOH, breaking zope.filerepresentation's dependency on zope.container might be a win (I dont know what else depends on zope.filerepresentation). zope.filerepresentation depends only on zope.container.interfaces.IReadContainer and zope.container.interfaces.IWriteContainer.
I'd favor moving the interfaces from zope.filerepresentation into zope.container itself and abandoning the zope.filerepresentation package. Hanno
Hey, Chris McDonough wrote:
On 5/14/09 11:05 PM, 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).
I found out that zope.container<->zope.filerepresentation is a direct circular dependency and that zope.filerepresentation is a package containing only interfaces. So breaking this dependency won't get us much for zope.container.
I should've read on before I gave you the same answer. :) We found this out during our analysis during the dependency refactoring sprint we had a few months ago. In this I find graphs an invaluable tool, especially sccmap which I mentioned just now in another reply.
OTOH, breaking zope.filerepresentation's dependency on zope.container might be a win (I dont know what else depends on zope.filerepresentation).
That I don't know. I don't expect it's much, however, as otherwise zope.filerepresentation would've seen seen in larger cycles during sccmap analysis. Regards, Martijn
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
On Friday 15 May 2009, Martijn Faassen wrote:
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.browser should not become an iface garbage collector. I think that interfaces not related to browser code deserve a new interfaces package. On the other hand we could rename zope.browser to zope.common or so. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Friday 15 May 2009, Martijn Faassen wrote:
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.browser should not become an iface garbage collector. I think that interfaces not related to browser code deserve a new interfaces package.
Sure, that's why I said it's tempting, not that we should do it. When refactoring for dependency cleanup, we should do mechanical analysis about what we could move. We should also always consider whether moving it makes enough sense. And we should consider the goals of moving anything. Chris did the mostly mechanical analysis but didn't speak much about goals. Now I'll do a bit of "does moving stuff make sense" analysis: I think these relate to browser code: * browser.IBrowserRequest, * browser.IBrowserPublisher * NotFound * IDefaultViewName, * IPublishTraverse This one doesn't: * xmlrpc.IXMLRPCPublisher These don't seem to either: * ITraversable * IContainmentRoot I'm don't think there's a clear case to move any of these, however - these interfaces belong in their packages, and moving these interfaces down into zope.browser would move assumptions into zope.browser about the way the publisher works, and we'd still depend on this stuff with zope.container. Let's think about goals. A possible goal is that we'd like to make zope.container independent from zope.publisher and zope.traversing. This way people who use other traversal and publication mechanisms could still use zope.container's implementation. I think there are realistic chances alternative publication and traversal mechanisms will arise, so I think this is a realistic goal at least to consider. Let's look again at zope.container in that light. It depends on zope.publisher and zope.traversing to support traversing into the container by the publisher. The direct dependencies are: * some test depencencies. these are easiest to get rid of * bits of configuration in configure.zcml that set up the item traverser * related to that, bits of implementation in traversal.py that implement this traversal behavior. * For zope.traversal additionally some of this code is set up in zope.container.testing for reuse. If we wanted to make zope.container agnostic about traversal and the publisher, we'd need to move this code somewhere else. I cannot think of an existing package for this (anyone?). Lacking that, I'd suggest a new package, zope.containertraversing or something like that. That is one of these new packages some people object to. :) It would have a clear focus however: equipping the container with traversal behavior so it works with the zope publisher. Alternatively we could keep the code in zope.container and only enable it if zope.traversing and zope.publisher are installed, much like what Chris did with zope.app.dependable. It does worry me a little that this makes the code a bit harder to reason about however, plus it leaves a module in place people who know nothing about the publisher can still run into. Perhaps an acceptable trade off, perhaps not. Looking at zope.container, cutting out zope.publisher and zope.traversing (or making them optional) would allow us to cut the following from zope.container's dependency graph: zope.traversing zope.publisher zope.i18n zope.exceptions zope.authentication zope.browser Regards, Martijn
Previously Martijn Faassen wrote:
If we wanted to make zope.container agnostic about traversal and the publisher, we'd need to move this code somewhere else. I cannot think of an existing package for this (anyone?). Lacking that, I'd suggest a new package, zope.containertraversing or something like that.
It could be an extra ;) Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
participants (5)
-
Chris McDonough -
Hanno Schlichting -
Martijn Faassen -
Stephan Richter -
Wichert Akkerman