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

[Philipp von Weitershausen]

Brandon Craig Rhodes wrote:
> I would love to lead a sprint based on my PyCon presentation, which
> will be on Saturday, and will be about how cool the Zope object
> framework is, and how easy Grok makes it to create and use adapters.
> It is annoying that I'll have to say:
> 
>   - "Adapters are neat!"
>   - "An adapter framework is even better!"
>   - "Zope gives you one!"
>   - "Grok makes it easy to use!"
>   - "And, oh, yeah, you can only grok things if you're willing to wait
>      for this big web framework to "import", which will make your shell
>      script that uses adapters take several seconds.  Oh, well."
> 
> I'd love to be able to finish my presentation, instead, with:
> 
>   - "And if you want to use Grok adapter coolness outside of the web
>      framework, then come to my sprint and we'll finish up grokcore
>      (is that what it was going to be called?) that splits the
>      cool-grokking-abilities of Grok from the expense of importing all
>      the machinery behind Views and XML and everything else."

'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 pretty much every grokcore package would need the <grok /> 
ZCML statement and the grok.testing.grok() facility for unit tests. 
That's why we need a 'grokcore.config' (or similarly named) package that 
contains zcml.py, meta.zcml and the necessary test helpers from 
testing.py. Grok itself and every grokcore package would then depend on 
'grokcore.config'. (In my experimental branch I called this package 
'grokcore.grok', but I think that name is rather confusing.)


[1] http://svn.zope.org/grok/branches/philikon-grokcore.component

> Or something like that.  Two other possible alternate topics, if
> splitting out grokcore is too big a job for sprinters, or if PvW still
> wants to implement that on his own instead of having some sprinters
> foul it up, are:

Nah, go ahead if you like.

>   - Looking at ways that zope.interface and zope.component could be
>     made to import and run faster.  I've noticed that my commands that
>     use them take several tenths of a second just to start up, and it
>     would be neat to make them leaner so that everyone could use them
>     at much less cost.
> 
>   - Doing the design and a first implementation of that neat adapt()
>     method that I proposed, and got grudgingly accepted by Jim Fulton,
>     late last year on the Zope mailing list.  That could be a really
>     cool topic for a sprint, since people wouldn't have to know much
>     about Zope, since it would basically just be repackaging existing
>     functionality in a much improved interface.
> 
> It would be neat if, on the sprint page, Grok's name appeared
> alongside things like Django and Turbogears as a framework that's
> serious enough to deserve its own sprint.
> 
> On the other hand, the PyCon web site indicates they really wanted the
> sprints defined by the start of registration - more than a month ago,
> in other words! - so maybe they wouldn't appreciate a late addition?
> 
> 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.