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

[Martijn Faassen]

Hey JW,

Thanks very much for this overview!

On 01/05/2011 02:49 PM, Jan-Wijbrand Kolman wrote:

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

I'll note that many in the Grok world already have used Fanstatic in its 
previous incarnation, named "hurry.resource". The main difference is
that Fanstatic can also serve static resources itself. And that 
Fanstatic is tremendously more polished and documented. :)

[fanstatic change implies]

I think another change is that the Zope static resource publisher, for 
better or worse, publishes even .html files as zope page templates, i.e. 
it tries to interpret TAL in it. If you've been relying on this, it 
won't work with Fanstatic.

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

I'm in favor of 2), to preserve the compatibility. I think in the case 
that someone really wants to extract a reusable library, they can go 
all-Fanstatic themselves. It's also Grok's job to automate registration 
tasks, and I think this includes Fanstatic registration tasks. I think 
it's okay for grokcore.view to rely on Fanstatic. Can we drop the 
dependency on zope.browserresource when we do that?

>       * Quite possibly there're several packages out there that somehow
>         rely on the ``static`` attribute that need to be updated in some
>         way.

I think there's some interesting interaction if you have a macro in 
package A, and then a template in package B that uses it.

If you use a static resource in the macro, it will fail if you're in 
package B as it'll look in the 'static' of package B, as opposed to the 
static of package A, unless you explicitly spell out the package name in 
the 'static' inclusions in the macro (I forget the exact spelling...)

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

I guess we'll just have to learn to live with such churn...

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

I hope the new zope.app.appsetup 3.15.0 is in there that fixes the error 
logging issue. :)

> * Official documentation, community documentation
>
>     Lot's of work was done on the documention. Great!

I agree, really great!

> 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!!

I agree, this is a good list! Much of this work started in the sprint, 
so it's really good to see progress at this in the last few months. We 
should start planning the next sprint to keep the momentum going.

Regards,

Martijn