[Grok-dev] Re: grok in the egg universe

[Philipp von Weitershausen]

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

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

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

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