extracting things out of zope.app.component
Hi there, We're working (at a small Grok sprint) on refactoring bits of Zope to reduce the insane dependency relations that exist between some packages. The goal is a nice layered dependency structure for Zope 3 packages. To that purpose Brandon Rhodes and myself started extracting things from zope.app.component. zope.app.component was a rather confusing package; it had a README.txt that was lying about the existence of 2 out of 3 other txt files. It takes care of registering some ZCML directives (class), it offers local site management facilities, and it has some ZMI to deal with that. As a first step we've extracted zope.site out of zope.app.component. It only cares about site management, not about introducing ZCML directives or about a UI. We've left backwards compatibility imports in the old package (not deprecation warnings because of a conclusion reached that appeared to have been reached about not using those in a recent discussion). Right now it doesn't reduce dependencies yet. It's a step however, as we're going to go through the existing packages and change imports. We're also going to extract the ZCML directive registrations from zope.app.component into its own package. What will be left in zope.app.component will be backwards compatibility code and ZMI stuff. Regards, Martijn
Martijn Faassen wrote:
We're working (at a small Grok sprint) on refactoring bits of Zope to reduce the insane dependency relations that exist between some packages. The goal is a nice layered dependency structure for Zope 3 packages.
This is awesome news :) I maintain dependency graphs for all zope packages included in Zope2 trunk at http://hannosch.eu/dependencies/zope/. Those should be correct covering the state from yesterday before your release-marathon. But I think the depdendencies didn't change for any of the packages I cover. If you want to generate those yourself, to get an easy graphical way of understanding the mess, then the following steps should get you there: easy_install tl.eggdeps Thanks Thomas! This parses the requires.txt in the egg_info folders. So make sure they are updated after you edit any setup.py files. Run: eggdeps -x -d zope.foo -i setuptools > zope.foo-full.dot [-x ignores extras, -d specifies a dot file as output, -i ignores setuptools] In order to make the graphs more readable you can remove the transitive dependency edges from the graph: tred zope.foo-full.dot > zope.foo.dot And finally produce a nice visual graph: dot -Tjpeg zope.foo.dot > zope.foo.jpeg [-Tsvg or -Tpng should work as well] tred and dot are part of graphviz. If you happen to run Mac OS and use MacPorts you need to install graphviz-devel instead of the graphviz port for tred to work. In the latest stable graphviz port tred is broken. Hanno
Hi, On Tue, 27 Jan 2009 19:49:16 +0100 Hanno Schlichting <hannosch@hannosch.eu> wrote:
[... nice eggdeps and graphviz info ...]
tred and dot are part of graphviz. If you happen to run Mac OS and use MacPorts you need to install graphviz-devel instead of the graphviz port for tred to work. In the latest stable graphviz port tred is broken.
We're doing that already, but thanks for the pointer. One thing we found is that tred makes the graphs way to nice and doesn't hint you at the problematic points. We manually isolated packages that we find sufficiently 'nice' and ignore those manually (like zope.interface). After that the graph only contains the messy parts but becomes a bit more readable. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote:
On Tue, 27 Jan 2009 19:49:16 +0100 Hanno Schlichting <hannosch@hannosch.eu> wrote:
[... nice eggdeps and graphviz info ...]
tred and dot are part of graphviz. If you happen to run Mac OS and use MacPorts you need to install graphviz-devel instead of the graphviz port for tred to work. In the latest stable graphviz port tred is broken.
We're doing that already, but thanks for the pointer. One thing we found is that tred makes the graphs way to nice and doesn't hint you at the problematic points. We manually isolated packages that we find sufficiently 'nice' and ignore those manually (like zope.interface). After that the graph only contains the messy parts but becomes a bit more readable.
Sure. That's a good approach. I found looking at the full dot files or grepping through them to work quite well for certain tasks. The reduced graphs gives you an easy way of seeing which packages can already be declared nice. For the actual dependency analysis of the messy ones, you need to dig deeper :) Hanno
Hey, Hanno Schlichting wrote:
Martijn Faassen wrote:
We're working (at a small Grok sprint) on refactoring bits of Zope to reduce the insane dependency relations that exist between some packages. The goal is a nice layered dependency structure for Zope 3 packages.
This is awesome news :)
I maintain dependency graphs for all zope packages included in Zope2 trunk at http://hannosch.eu/dependencies/zope/. Those should be correct covering the state from yesterday before your release-marathon. But I think the depdendencies didn't change for any of the packages I cover.
Yeah, zope.site isn't completed yet, as currently zope.app.component relies on zope.site and vice versa. The vice versa needs to go away and that can be done by extracting more from zope.app.component (the implemnentation of various ZCML directives) into another package. [snip explanation] Thanks for the explanation. We are using tl.eggdeps and dot as well already, though.
In order to make the graphs more readable you can remove the transitive dependency edges from the graph:
tred zope.foo-full.dot > zope.foo.dot
This also takes some information about dependencies we'd like to remove from the graph, so instead we've created the full messy graph but removing nodes that are already have no dependencies, or have clear layering (such as zope.interface, zope.component). The remaining graph then gives us clues about what we should focus on. Regards, Martijn
participants (3)
-
Christian Theune -
Hanno Schlichting -
Martijn Faassen