[Grok-dev] Re: a PyCon sprint for Grok?

Martijn Faassen faassen at startifact.com
Wed Mar 12 07:30:47 EDT 2008

Philipp von Weitershausen wrote:
> 'grokcore' is supposed to be the namespace package for the various parts 
> that make up grok. I once started an experimental branch where I tried 
> to separate the grokkers for adapters and utilities 
> ('grokcore.component') [1]. Even though I abandoned the branch (and by 
> now it is completely outdated), I refactored the grok trunk shortly 
> afterwards so that the separation would be much easier to do in the 
> future. It can also serve as a guide of what the separation would look 
> like if/when done again.

Note that I realized that 'grokcore.component' may be stepping on 
namespaces a bit much perhaps, as we often do things like 'from zope 
import component'. (note that 'grok.core' is out; 'grok' is not a 
namespace package just a plain package with things in it). Anyway, 
perhaps 'grokcore.component' it is still, as long as we don't require 
people to import from it a lot in daily life. Just wanted to note about 
the potential (non-lethal) name clash.

>> In which case, if we Grok fans wanted to join an existing sprint, what
>> would we join?  I note that Tres and Chris are running a WSGI-fication
>> sprint for web frameworks; are there any aspects of Grok WSGI-fication
>> that are left to be completed?
> Well, Zope 3's zope.publisher supports WSGI. With version 2.5.0, it 
> actually gained a WSGI-spec application class (which before we always 
> took from zope.app.wsgi, which is not as flexible). So technically, it's 
> just a matter of using a different template for grokproject to get a 
> WSGIfied Grok.
> There is also Repoze, however, which expoded the Zope 2 publisher. The 
> same could be done with the Zope 3 publisher. The nice thing is that 
> Repoze already provides middlewares for virtual hosting, transaction 
> management, etc. So we'd really be looking at "light" versions of 
> zope.publisher + zope.app.publication that basically don't do these 
> things at all.

Yeah, we need to make some decisions on the way to go here. Repoze is 
nice as it has some momentum in this domain. I think the main work for 
the WSGI support is to come up with something that:

* works out of the box

* includes some nice WSGI components (like the exception formatter)

* is documented out of the box: "this is how you do Grok with WSGI"

Right now it's a bit too much "it's possible, you can roll your own, 
please select any of these various methods, and what do you mean, you 
want to see documentation?"

Note that if you are going to hack on grokproject it'd be nice to sync 
it up with zopeproject as much as we can.



More information about the Grok-dev mailing list