Hi there, This is a progress report on the package dependency refactoring work. We've had a lot of people contribute to this process (thanks everybody!), and bit by bit we are able to make a serious impact on dependencies. Yay! Let's take for example zope.app.publisher, which a few weeks ago had a dependency structure like this: http://startifact.com/depgraphs/zope.app.publisher-before.svg (60 dependencies, including zope.app.form and zope.formlib). After a lot of work on a lot of packages, we now have a dependency structure like this: http://startifact.com/depgraphs/zope.app.publisher-after.svg (45 dependencies, no more form related stuff) Still a big graph, but a lot simpler nonetheless, and down 15 packages. So, due to the recent changes we've now managed to cut away zope.app.form and zope.formlib entirely from zope.app.publisher's dependency chain (except for the tests). The main dependency cycles we started out with in the big graph were these: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg After some work we'd gotten it down to this: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg And by now the main cycles left are these: http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher <--> zope.app.publication <--> zope.app.http And also this (familiar) one: zope.container <--> zope.filerepresentation I need to do some more analysis to see what other complexities we have in the dependency chain in the ZTK. One obvious set of tasks is to continue evaluating dependencies of things like zope.app.publisher to see whether we cannot take out a few more. Just study the graph and see what can be done by examining the code: http://startifact.com/depgraphs/zope.app.publisher-after.svg For instance, what is zope.app.pagetemplate doing depending on zope.dublincore? What about its direct dependency on zope.container? Another set of tasks is to examine all the test dependencies we have, as those are way more complicated than the main dependencies. Ideally our test dependencies shrink to nothing as well. This will be a hard slog as we rewrite tests, but we can target one dependency at the time, too. Regards, Martijn