Hi. I allowed myself to work on the Zope Toolkit over x-mas and make some decisions to get some progress ;-)
The good news is that all our herculean efforts to unclutter the dependency structures have really payed off. Only very few zope.* packages still have dependencies on zope.app packages. I excluded those misbehaving packages from the ZTK to reflect this and noted them in a "unresolved-dependencies" option. The ZTK no longer contains any zope.app packages with one exception. There's a number of problematic packages, where I'd like some other opinions on how to proceed. zope.traversing It has a dependency on zope.app.publication. Given the central role of zope.traversing I allowed it and zope.app.publication to stay in the ZTK, but moved it to the under-review option. We have talked about refactoring the traversal and publication story in the past, without seeing any consensus on how to move forward with it. My feeling tells me, that a pure renaming of zope.app.publication to zope.publication or similar code reshuffling into other packages isn't really helpful in this case. ACTION: Until we see further progress on clarifying the semantics of traversal and publication, I'd leave zope.app.publication in the ZTK. zope.catalog and zope.intid Both of these have a dependency on zope.app.testing. Their tests heavily rely on a functional test setup with a ZODB and persistent data. They don't seem to need a publisher or a web server, though. ACTION: Remove them from the ZTK. Once their test setup no longer relies on zope.app.testing, they should move back into the ZTK. zope.file I think this package is just misnamed and should have been zope.app.file. It's a full blown content type implementation, with dependencies on zope.app.form, providing browser view code, browser menus and quite a bit of zope.app integration. It's test setup needs a full blown ZODB and publisher environment. ACTION: I'd remove this from the ZTK until someone is willing to refactor it to provide a minimal file implementation. zope.formlib and friends zope.formlib depends on zope.app.form which in turn depends on many zope.app packages. zope.html and zope.mimetype both depend on zope.formlib or zope.app.form. Various people myself included looked at the zope.formlib / zope.app.form split to see if it can be refactored in a sensible way. I think the conclusion has so far been: there's just no way. There isn't a sensible set of basic principles or interfaces in formlib, that can form a base for a higher level zope.app.form. All the packages using formlib today actually make use of the widgets in zope.app.form and thus basically on the entire functionality. With z3c.form we have another independent form library from the Zope community, which has seen at least as widespread if not more adoption. Preferring one over the other doesn't make much sense to me. ACTION: At this point I'd suggest to drop zope.formlib, zope.app.form and packages that depend on it from the ZTK. zope.testbrowser This package offers functional browser tests and consequently needs a way to set up a ZODB and publisher with some default application configuration. I don't see how this can be achieved without depending on a specific application environment like zope.app.appsetup or Zope2/App. Zope2 depends on the package and it makes sense to include it on the application server level - but not on a toolkit level for building frameworks. ACTION: I'd suggest to drop this package from the ZTK. Merry x-mas :) Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
