[Grok-dev] strategy for losing the zope.app packages

Martijn Faassen faassen at startifact.com
Thu Dec 3 11:04:02 EST 2009


Hi there,

When we migrate to the ZTK we would like new installations of Grok not 
to depend on zope.app packages where we can avoid it. Making Grok as 
clean as possible from zope.app packages would also help us making sure 
we get the dependencies in Grok and grokcore.* right.

On the other hand, we don't want to break a whole lot of existing 
packages that do rely on zope.app packages. We don't want to break 
imports. Worse, we wouldn't want to introduce persistence problems. We 
want to give people time to migrate smoothly to a pure ZTK-ed Grok.

How do we fulfill both use cases? I think we need a grokcore.backwards1 
(better name?) package that promises backwards compatibility with Grok 
1.0. The main thing this package would do is depend on all the 
zope.app.* packages that Grok 1.0 depends on (even indirectly), in its 
setup.py.

This way we could eliminate these dependencies from Grok itself. 
Hopefully we can make Grok as zope.app free as possible (also in its 
ZCML including; no zope.app.zcmlfiles, for instance). If for some reason 
we can't drop a zope.app package, we should identify what's going on and 
perhaps refactor some zope.app packages where needed.

For grokcore.* I think we should be more ruthless and not provide 
backwards compatibility. grokcore.* packages are used as libraries and 
not as a framework environment, so I think we'd be all right in doing so.

What do people think? Volunteers?

Regards,

Martijn



More information about the Grok-dev mailing list