[Zope-dev] producing a list of packages in the Zope Framework?

[Martijn Faassen]

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