[Grok-dev] Re: grok in the egg universe
Philipp von Weitershausen
philipp at weitershausen.de
Tue Apr 17 18:22:49 EDT 2007
Martijn Faassen wrote:
>>>>> While I'm sure we want to do this soon, we don't want to break
>>>>> everything now.
>>>> The first step we could do is make Grok depend on the Zope eggs and
>>>> see how that works. As far as breaking things is concerned, you
>>>> mentioned that the grok package would still provide a common imports
>>>> for stuff from grokcore, so even here the breakage would be limited...
>>> Yes, but we can't do it with the trunk,
>> Not sure what you mean here.
> I just mean we should do this on the branch until this method is mature
> enough. That may indeed be very soon as you say below.
Soon has come sooner than expected. See below :)
>>> and the ability to run the whole Zope server from eggs is very new
>>> right now.
>> True, but if it works... :)
> Agreed. I would have no objection to move Grok over into the New Eggy
> World as soon as possible.
So since I've been wanting to play with this anyway, I went ahead and
did this tonight. Simply get the philikon-eggification branch of grok
and run the buildout. You'll see :).
Here's what I did:
* I explicitly stated Grok's dependencies on Zope 3 eggs (which are
available from http://download.zope.org/distribution).
* Since Zope 3 was going to be pulled in through eggs instead of a
checkout or tarball, the existing instance recipe wouldn't have a
mkzopeinstance script to call. I therefore switched the buildout
configuration over to the new zc.zope3recipes :app and :instance
recipes. These recipes have a few benefits:
- They're more current and under active development. I was a bit
unsatisfied with zc.recipe.zope3instance, it had lots of small
- They allow you to separate an application definition from an
instance definition. It is quite easy to duplicate the same
application onto several instances (e.g. for ZEO). Nothing really
exciting for the Grok development checkout, but possibly for
- The instance recipes installs a "bin/<name_of_buildout_section>"
scripts which looks like zopectl. "bin/instance fg" starts the
eggified Grok instance.
One thing that I find a bit awkward is the verbatim inclusion of
site.zcml into the buildout configuration. I would prefer if you could
simply point to a separately maintained file. Perhaps you can, I need
to check that out.
* zc.zope3recipes:instance no longer creates a full-blown instance, it
just creates a zopectl-like script, a zope.conf and a site.zcml.
That's really all that's needed to run Zope 3 anyway.
One caveat is that there's no standard ftesting.zcml to rely on for
functional tests anymore. That's really a blessing because we should
really be defining our ftesting dependencies ourselves (and so we did,
in buildout.cfg in a [testinstance] section). So, what I did is create
an ftesting.zcml and a GrokFunctionalLayer from that and put all
ftests on that layer. Tests happily pass on the eggification branch.
(This test work was lifted off of my philikon-grokking-tests branch
which, apart from the introduction and simplification of the ftesting
layer, I now consider a failed experiment.)
Given that it all seems to work (please test it for yourself!) and that
Zope 3.4 is alphaing soonish (and we're sadly not releasing at all
currently), I again state my opinion that this should be a short-lived
I also plan to feed back those changes to grokproject, making an
egg-based install the default, unless you provide --with-zope3= to point
to a traditional Zope 3 installation or checkout.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev