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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
