Hey Christian, Thanks for picking up on this discussion. Christian Theune wrote: [snip]
It might be a goal to get rid of all of zope.app with respect to the Zope Framework definition.
Our *goal* is not to have any zope.app package within the framework. zope.app should be useful for Zope 3 as it provides the ZMI and backwards compatibility, but I hope that Grok and Zope 2 can move away from using zope.app.* packages very soon. But today, the major users of the wider Zope Framework (Zope 2, Zope 3 and Grok) all do use these packages, so it's our business to take care of them. Until the zope.app.* packages have all become backwards compatibility stubs, deprecated code and the home for the ZMI we have to continue to take responsibility for it.
zope.broken
Hmm. There's only a single marker interface in that package.
Created by Tres recently, to remove a further dependency from zope.container. We'll have to discuss what to do with packages that don't seem to carry their weight at some point, but let's go with it for now. [snip]
zope.datetime
Is this actually still needed? It looks like this pre-dates Python's datetime module. There's also pytz around.
I don't know, does other code refer to it?
zope.deferredimport
I feel like we might wanna keep it although we want to avoid deferredimports.
It'll have to stay around as we use it for now. But we might at some point decide that zope.deferredimport (with its rather heavy dependency on zope.proxy which has C code) is more trouble than it is worth. Right now the policy is: * If zope.deferredimport is used in a package merely to avoid the use of ``from`` imports, then instead we will use ``from`` imports to get rid of this dependency. [snip]
Parts of the Zope 3.5 KGS not required by Zope 2.12 / Plone 4
Most of the following list I agree to exclude, except the ones I marked up. Some I'm not sure about.
zope.catalog
+1 for keeping
I agree we should keep the catalog, intid and indexing infrastucture as something we care about. We should also investigate things like zc.catalog as something within the framework.
zope.decorator zope.documenttemplate zope.file zope.html zope.index
+1 for keeping
I think zope.documenttemplate should eventually be able to live as a template language implementation that can plug into the framework as opposed as an integral part of it. How do we proceed? Shall we take Hanno's list as a starting point, put it in our documentation for now, and then weed out bits on a case by case basis? (continuing this discussion) Regards, Martijn