various ZTK observations
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
On Sep 21, 2009, at 11:42 AM, Martijn Faassen wrote:
* zope.minmax: is this package being used? If not, we could consider removing it from the ZTK.
It's easy to find that it's used by zope.session. It is used for conflict resolution. Regards, Zvezdan
Zvezdan Petkovic wrote:
On Sep 21, 2009, at 11:42 AM, Martijn Faassen wrote:
* zope.minmax: is this package being used? If not, we could consider removing it from the ZTK.
It's easy to find that it's used by zope.session. It is used for conflict resolution.
Thanks for that bit of information! After all my analysis I hadn't gotten around to grepping yet. Looks like it's staying in the ZTK then. (and it's possible for libraries to be unused within the ZTK but still used outside it by a significant amount of consumers; we need to know about both, and the latter is harder to find out). Regards, Martijn
Martijn Faassen wrote:
* zope.contenttype: we should analyze what is using zope.contenttype.
Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file and zope.app.onlinehelp are. There's also zope.mimetype which seems to be concerned with the same subject and is used by zope.file and zope.html, and there's some MIME-type handling being done without using either zope.contenttype or zope.mimetype by zope.publisher and possibly others. Last time I looked, these different pieces of code didn't even treat content type declarations consistently nor correctly wrt the relevant RfC. I guess one might want to clean up this story as a whole. -- Thomas
Thomas Lotze wrote:
Martijn Faassen wrote:
* zope.contenttype: we should analyze what is using zope.contenttype.
Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file and zope.app.onlinehelp are. There's also zope.mimetype which seems to be concerned with the same subject and is used by zope.file and zope.html, and there's some MIME-type handling being done without using either zope.contenttype or zope.mimetype by zope.publisher and possibly others. Last time I looked, these different pieces of code didn't even treat content type declarations consistently nor correctly wrt the relevant RfC. I guess one might want to clean up this story as a whole.
Thanks for doing this analysis! It'd be great if you could turn this into a proposal for future actions... I'm surprised about the difference in dependencies between zope.file and zope.app.file: isn't zope.file an extracted version of zope.app.file? If not, we need to think about that too. Regards, Martijn
Martijn Faassen wrote:
Thanks for doing this analysis! It'd be great if you could turn this into a proposal for future actions...
Do you mean a proposal that would go in the "Proposals" section of the ztk docs?
I'm surprised about the difference in dependencies between zope.file and zope.app.file: isn't zope.file an extracted version of zope.app.file? If not, we need to think about that too.
It isn't, they both have a long separate history. They also provide completely unrelated interfaces and implementations of file content objects. -- Thomas
Thomas Lotze wrote:
Martijn Faassen wrote:
Thanks for doing this analysis! It'd be great if you could turn this into a proposal for future actions...
Do you mean a proposal that would go in the "Proposals" section of the ztk docs?
A proposal on the mailing list to start with, but of course if we managed that on Launchpad that'd be good too. :)
I'm surprised about the difference in dependencies between zope.file and zope.app.file: isn't zope.file an extracted version of zope.app.file? If not, we need to think about that too.
It isn't, they both have a long separate history. They also provide completely unrelated interfaces and implementations of file content objects.
Oh, how fun. :) Regards, Martijn
participants (3)
-
Martijn Faassen -
Thomas Lotze -
Zvezdan Petkovic