[Grok-dev] towards a Grok release: current state of affairs
janwijbrand at gmail.com
Wed Jan 5 08:49:49 EST 2011
A lot is going on in Grok-world currently and by now so much has done
that we would like to see a release Soon Now.
I'll try to summarize the current state of affairs:
* grokcore.xmlrpc, grokcore.rest, grokcore.traverser
The REST and XMLRPC components have been split from grok itself
(thank you people who worked on this!) into respectively
grokcore.rest and grokcore.xmlrpc.
While at it, the traverser components that support the REST and
XMLRPC components have been separated out into grokcore.traverser.
These new grokcore.* packages all have been released now and the
Grok Toolkit has been updated to make use of these versions. The
grok *package* containing the necessary changes has not been
The groktoolkit trunk still uses a development checkout for grok.
* grokcore.site changes
The getApplication() function and IApplication interface has moved
from the grok *package* to grokcore.site. grokcore.site has been
released and the Grok Toolkit has been updated with it.
We know grokui.admin is wants to import IApplication and it has been
updated to import it from grokcore.site now. The groktoolkit trunk
still uses a development checkout for grokui.admin.
Also the grok package itself has been updated to import
IApplication and getApplication() from grokcore.site. This means we
need an release of the grok package for this as well.
This already warrants a 1.4 release if you ask me. However, we have
even more changes up our sleeve:
* Landing Fanstatic into grok, grokproject
As you most probably already know, we're about to change the way
Grok will handle static resources. This rather significant change
will be based on the Fanstatic project.
Fanstatic provides several WSGI components for automatically
HTML, and for publising resources (offloading this responsibility
from Grok itself).
What would the Fanstatic integration in Grok imply:
* grok.View components have a ``static`` attribute that is set to
a ``DirectoryResource`` instance whenever there is a 'static'
directory available. This ``static`` attribute on view allows
for computing URLs to resources in Python and in Page
Templates like so::
self.static['foo']['bar.png']() # in a view class.
tal:attributes="src context/++resource++foo/bar.png" # in zpt.
This functionality comes from ``zope.browserresource``.
If Fanstatic were to replace the ``zope.browserresrouce``
functionality, the ``static`` attribute on views needs to be
replaced too. The ``zope.fanstatic`` glue-package provides
this. This package allows for computing resource URLs in both
Python code and Page Templates like in the example above.
If there're more use case or patterns that might need to be
re-implemented in the ``zope.fanstatic`` package, then we would
very like to hear about them!
* Fanstatic requires libraries of resources to be registered
through entry-points. This is a nice cross-framework way of
doing, but could perhaps be confusing for people used to using
the ``static`` attribute on views in Grok: the ``static``
attribute currently is set by way of a Grokker that is able to
determine whether there in fact is a "static" sub directory for
For the Fanstatic integration we now need to choose from two
1) Require all "static" directories to be declared as
entry-points. Projects created through the ``grokproject``
tool could provide for an example setup to show how this is
done (and of course there will be upgrade documentation for
2) keep the Grokker that looks for "static" directories and have
it register the correct Fanstatic libraries of resources.
The advantage of 1) is that there's one clear way for
registering libraries of resources, even if people need to learn
that this "registration" is now not done automatically anymore
*and* is different from other ways of registering components in
Grok. Another advantage is, that there is no hard dependency
for grokcore.view on Fanstatic.
The advantage of 2) is that the current behaviour of the
"static" directory is kept as closely as possible. Even if there
would now be in fact two ways for registering libraries of
resources in Grok. With such a grokker we would also introduce a
hard dependency on Fanstatic.
* Quite possibly there're several packages out there that somehow
rely on the ``static`` attribute that need to be updated in some
* Jan-Jaap did quite some work on grokproject so that is able to
create project using Fanstatic. After landing Fanstatic in Grok,
we need to release grokproject too.
This release would again result in a grokproject version that
will not be able to create projects based on an earlier Grok and
the other way arround. I see no way to prevent this, but it
makes me wonder again about the strong ties between a Grok and a
* ZTK-1.1 on the horizon
There're concrete plans to release a ZTK-1.1 next week. Why next
week? Well, that's because, as a member of the ZTK-releaseteam, I
sugested to make an ZTK soon as the next Grok release is imminent
and Grok would like to use a recent ZTk if possible.
Of course we need to check the Grok Toolkit against a recent ZTK,
but I do know the Grok Toolkit already defines newer versions for
several packages overriding version in ZTK-1.0.x.
It is on my plate to look into this.
* Official documentation, community documentation
Lot's of work was done on the documention. Great!
The plan is to move the "official" "doc" sub directory from the grok
package to groktoolkit package. This would make writing
documentation for Grok-the-project easier and the Grok Toolkit would
then also be the place for the documentation toolchain. The grok
package is getting more and more a "mere" import hub, like we
planned it to be during the Forest Sprint.
I'd like to see the documentation moved before the next Grok
release. This is on my plate and I'm planning to do this this
Moving the documentation is on my plate. Like is deploying the
scripts that would make regular builds of the documentation (both
official and "community") on grok.zope.org.
* Test-setup in Grok projects
Grokproject recently replaced the ``z3c.testsetup`` test aggregation
with a more "manual" approach in newly created projects.
This is in anticipation for the outcome of the ``py.test``
experiments currently conducted.
So, this summary turned out to be a longer list than I anticipated :)
But this is good: we have lots of progress in Grok - again, great!!
My idea of short term planning:
* In the upcomming Grok IRC meeting we should decide what to release
in 1.4 - will it include Fanstatic, or will we do a 1.5 (or 2.0??)
quickly after 1.4?
* Do a 1.4 release somewhere next week *or* try to land Fanstatic in
Grok (and grokproject), and determine a release schedule when the
Quite possible I forgot about issues, or perhaps made mistakes in the
assesment of the current state of affairs. Please do make corrections
kind regards, jw
More information about the Grok-dev