[Grok-dev] Grok emerging from the dependencies
faassen at startifact.com
Tue Apr 27 10:13:40 EDT 2010
As of yesterday, the Grok tests (mostly) run without zope.app.testing
and zope.app.zcmlfiles as well. Grok will run on a much cleaner set of
dependencies. This is the result of more than a year of work, yay!
So what does this actually mean? What have we gained? A number of things:
* dependency graph of what Grok uses is not a horrible rats nest of
complexity, it's a lot cleaner, easier to think about and
easier to reason about. It's still a huge graph, mind, but at least
one without cyclical dependencies.
* Grok uses less code. Most importantly, the whole ZMI codebase is gone
* Grok uses less dependencies itself. Grok 1.0 uses 113 dependencies.
At my latest count, Grok 1.2 will use 93 dependencies. That's 20
libraries less to think about. (I hope to shrink this further though)
* We can start looking at the future. I want to replace the Zope
publisher and traverser with something else (what? I'm not sure yet).
It should be easier to understand and more powerful in ways
that are useful. As a first step, this requires us to remove
the 'zope.publisher' and 'zope.traversing' dependency from a lot
of ZTK packages we are using.
I'm now working on fixing up the failing tests (most failures are due to
the now-missing ZMI) and trying to remove more dependencies (there are
some more zope.* and zope.app.* packages that can hopefully be removed
too). I also still need to do the magic test of actually *running* Grok. :)
I've also improved the buildout so you don't have to do anything special
in order to try this out. Just check out:
$ svn co
and run bootstrap.py and buildout. You can then run grok's tests:
buildout will auto-checkout grok and various grokcore.* packages, as for
those we need the development versions.
I've also removed grok-ecosystem on the branch. While I think it is
potentially useful, it slows down buildout enormously, and I also
discovered when running buildout without grok-ecosystem that
grokui.admin actually had two dependencies unpinned in grok.cfg itself:
megrok.layout and megrok.menu. It may be we need to split up a
grokui.cfg from grok.cfg in the future.
More information about the Grok-dev