faassen at startifact
Sep 21, 2009, 8:42 AM
Post #1 of 7
(756 views)
Permalink
|
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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
|
