[Grok-dev] Grok emerging from the dependencies

Martijn Faassen faassen at startifact.com
Tue Apr 27 10:13:40 EDT 2010


Hi there,

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 
svn+ssh://svn.zope.org/repos/main/groktoolkit/branches/faassen-testlayers 
groktoolkit

and run bootstrap.py and buildout. You can then run grok's tests:

$ bin/test-grok-grok

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.

Regards,

Martijn



More information about the Grok-dev mailing list