[Grok-dev] Grok emerging from the dependencies

Souheil CHELFOUH trollfot at gmail.com
Tue Apr 27 10:27:51 EDT 2010

Thank you Martijn for this work and I'm glad we are finally seeing the
bottom of the zope.app pit.
As for the megrok dependencies, you once talked about integrating the
megrok.layout to the grok core.
I think that would be a good think. It's, at least, as useful as
grok.View for many usages.
megrok.menu can be, in the long run, removed to use something more
powerful and more widespread.
It would be good if Grok community could try and work hand in hand in
producing higher level packages too, that are commonly used in many
website cases.

2010/4/27 Martijn Faassen <faassen at startifact.com>:
> 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
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev

More information about the Grok-dev mailing list