Hi there, We now have in the ZTK repository also a facility to create dependency graphs for the packages in the ZTK (thanks to Hanno's z3c.recipe.depgraph). http://svn.zope.org/zopetoolkit/trunk/ See the README.txt for more information. I reviewed some dependency graph for the ZTK the other day, focusing on the zope.* packages (and not looking at zope.app). Here are some of my observations: * zope.browserpage: puls in zope.app.pagetemplate which pulls in a lot, including zope.dublincore and the ZODB. * zope.browserresource: pulls in zope.site which pulls in a lot. I imagine the zope.site dependency cannot be easily avoided. This relates back to the zope.site refactoring ideas we talked about a while ago, making a core of zope.site that's not dependent on zope.container. * zope.contentprovider: would be nice if we could break its dependency on zope.publisher * zope.contenttype: we should analyze what is using zope.contenttype. * zope.documenttemplate: how many people are using zope.documenttemplate? I think this is a potential removal candidate for the ZTK. Also pulls in zope.structuredtext for some reason. * zope.structuredtext: how many people are using this? ReST is the community standard now. Removal candidate for the ZTK. * zope.error: pulls in quite a lot through zope.container, can we get rid of that connection? * zope.formlib: depends on a huge amount of stuff, including zope.app.form. I think zope.app.form's widgets should be moved out of zope.app. What about moving them into zope.formlib itself? There's also a zope.app.pagetemplate dependency. * zope.html: pulls in a huge amount, including zc.resourcelibrary, zope.formlib. Also contains checked in javascript sources of several javascript based editors, something I thought was against the licensing policies - I solve this problem by pulling in the editor when running setup.py instead of having to check in sources. Should this really be part of the ZTK? * zope.minmax: is this package being used? If not, we could consider removing it from the ZTK. * zope.modulealias: this package declares itself deprecated since 2006, and can be removed from the ZTK. * zope.principalannotation: depends on zope.site, which pulls in a lot. Probably need a more minimal dependency which does site stuff instead of zope.site. * zope.ptresource: pulls in a lot of stuff, in particular through zope.browserresource * zope.securitypolicy: depends on zope.authentication. Is that really necessary? * zope.sequencesort: who is using this? If nobody, consider removal from the ZTK. * zope.testrecorder: pulls in a lot. Who is using this? * zope.viewlet: pulls in zope.app.pagetemplate, which pulls in a lot of stuff. * zope.xmlpickle: who is using this? Refactoring opportunities with a big dependency win surround zope.site and zope.app.pagetemplate (and the libraries that depend on them). There are quite a few libraries that the rest of the ZTK doesn't depend on and at the same time have few or no dependencies on other ZTK libraries. This might make them candidates for removal from the ZTK if they aren't used by many people. These libraries: * apparently aren't foundational to the ZTK * don't depend on the ZTK - this would make them easy to maintain outside of the ZTK for those that *are* interested. Then again, for the same reasons they present minimal maintenance burdens to the ZTK maintainers, so keeping them isn't too difficult if there are users. That said, if they don't have sufficient documentation that *would* present a maintenance burden to us (we'd need to create it). Regards, Martijn