[Grok-dev] towards a Grok release: current state of affairs

[Jan-Wijbrand Kolman]

Hi,

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
   released however.

   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
   including resources like javascript and stylesheets etc. in rendered
   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
       the package.

       For the Fanstatic integration we now need to choose from two
       options:

       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
          this).

       Or,

       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
       way.

     * 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
       grokproject release.

* 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
   afternoon.

   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
     landing succeeded.

Quite possible I forgot about issues, or perhaps made mistakes in the
assesment of the current state of affairs. Please do make corrections
and/or suggestions!

kind regards, jw