[Grok-dev] Re: grok in the egg universe
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 16 11:58:25 EDT 2007
Martijn Faassen wrote:
>> I hope that now we can. In fact, I've been wanting to try this out.
> One thing I'd like to avoid is having the old 'whole Zope 3' approach
> next to the egg approach in a single buildout. While this might work
> (eggs for some tests, whole Zope 3 for the actual app serving), having
> two versions of the same code around would be quite confusing, so this
> is a situation I'd like to avoid.
Naturally. Fortunately Zope 3 is at a point where we can install a whole
Zope 3 application (including Zope 3 itself) from eggs (see baijum's
zwiki branch for an example).
>>> How do we accomplish this? One thing to do is to simply start listing
>>> the dependencies in Grok's setup.py. But we also need to carefully
>>> examine which dependencies Grok pulls in and try to minimize them as
>>> much as possible (the ZMI..).
>>> Then there are issues. Grok messes with Zope 3 security. We obviously
>>> don't want people's security to be magically turned off if they
>>> install a dependency that uses Grok.
>> In this case we need to differentiate Grok-the-configuration-system
>> from Grok-the-web-framework which comes with its own publication
>> object (which essentially is the heart of a Zope-based app server).
>> You mention this split-up below.
>> I would advise, however, to keep the number of packages that we
>> produce low. I would actually be fine with a 'grokcore' or 'groklib'
>> package that contains the generic stuff and 'grok' that contains
> There's also my old 'groklib' idea which just factors out the grokking
> process into a library, but doesn't rely on anything in Zope at all. I'd
> like to reserve the name 'groklib' for that.
Ok, fair enough.
> I'd still propose grokcore to be a namespace package. For testing
> purposes I'd really like a grokcore.component that only dealt with the
> core component architecture and didn't need to import anything from,
> say, formlib, or zope.app.
> This is in fact the concrete use case that drove this thinking. Having
> grokcore.component will help us with compatibility. If I release a new
> Zope 3 component that grokked its adapters (and only that), people would
> be much more likely to start using it if it didn't pull in the whole of,
> say, zope.app. Such a component would be functionally equivalent to a
> Zope 3 package with the equivalent ZCML.
Ok, as long as
* the 'grok' package makes all that default stuff available
* the documentation doesn't confuse users with a gazillion different
packages with slightly different naming. What I'm trying to say is
that the docs should also *advise* importing things from 'grok'.
I guess I'm preaching to the choir here anyway... :)
>>> 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.
> and the ability to run the whole Zope server from eggs is very new
> right now.
True, but if it works... :)
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev