[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