Thanks for picking up on this discussion.
Christian Theune wrote:
> 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
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.
> Hmm. There's only a single marker interface in that package.
Created by Tres recently, to remove a further dependency from
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.
> 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?
> I feel like we might wanna keep it although we want to avoid
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.
>> 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.
> +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.
> +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)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -