[Zope-dev] Zope Toolkit - packages with zope.app dependencies

[Hanno Schlichting]

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