[Grok-dev] grok-martian branch ready for your testing pleasure

Martijn Faassen faassen at startifact.com
Wed Jun 20 09:22:09 EDT 2007

Hi there,


Your task is to test your application with the grok-martian branch (by 
checking it out as a 'develop' package in your own buildout) and letting 
me (through the list) know whether there are any problems.

The branch is here:

svn co svn://svn.zope.org/repos/main/grok/branches/grok-martian

(this will pull martian in as an external)

The tests all run on my machine (after doing the appropriate buildout). 
The wiki also works. I want to know whether your code still works.

Expected problems

Some expected problems that should be easy to fix for you:

* you define your own grokker. Check out martian's src/martian/README.tx 
t for information and look at the existing meta.py in Grok for how to 
use the new martians. In brief: different base class, method is now 
called 'grok', and changed parameter order (name, factory are always the 
first two parameters).

* you try to import something from grok.util in your code and it isn't 
there. Instead import it from martian.util. I don't think this should 
happen unless you define your own grokker or directive.

* you try to import something from grok.directive in your code and it 
isn't there. Instead look for it in martian.directive. I don't think you 
will have this problem unless you define your own directive.

I didn't provide for backwards compatibility as these problems should 
occur in very few extensions, and should be easy to fix if they do.


While I said that I wouldn't get around to finishing Grok's martian 
integration until weeks from now, I kept running into things I wanted 
from it in my other work, so I bit the bullet yesterday and finished the 

What does this gain us?

* to the average Grok developer: Grok will continue to work as before, 
so very little. However, eventually (we're not there yet):

   * grok-based zope 3 packages that can be reused inside Zope 3 
projects without any worry

   * some infrastructure to make it easier to test grok-based 
applications. It becomes easier to grok specific objects or define a new 
grokker from within a doctest.

* to the grokker developer: a better documented grokker infrastructure 
in martian.

* to the grok core developers: the way is now open for us to start 
splitting up grok into grokcore.* packages. This should allow us to 
build better compatibility with Zope 3. If you depend on a grokcore.* 
package with your own package you get many of the benefits of Grok 
without Grok turning off Zope 3's security infrastructure.

* to Python developers: an advanced, pluggable configuration 
infrastructure in Martian.



More information about the Grok-dev mailing list