[Zope-dev] various ZTK observations

Martijn Faassen faassen at startifact.com
Mon Sep 21 11:42:44 EDT 2009


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



More information about the Zope-Dev mailing list