[Grok-dev] Re: a PyCon sprint for Grok?
Philipp von Weitershausen
philipp at weitershausen.de
Wed Mar 12 05:53:07 EDT 2008
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') . 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.)
> 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
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.
More information about the Grok-dev