[Grok-dev] Re: First Experience with Grok

Martijn Faassen faassen at startifact.com
Sun Sep 16 09:00:56 EDT 2007

Hey Shane,

Shane Hathaway wrote:
> I've just started trying out Grok.  It looks very good so far!

Thanks for your kind words and great to see you on this list! I hope to 
see much more of you in the future.

> I'd like to point out one issue I stumbled on at first.  After running
> grokproject, the server would not start.  The exception I got was
> cryptic.  After studying it, I realized my system had an older version
> of zope.interface and Twisted installed in site-packages, and that the
> sys.path constructed by grokproject preferred the version in
> site-packages.  I fixed the problem by removing my site-packages path
> from the generated runzope.  I suspect site-packages should never be
> preferred over anything from the buildout-eggs directory.

Unfortunately this problem occurs frequently. Many people also have Zope 
3 installed in their site packages, which leads to similar problems.

One way around this is to use an installation procedure in grokproject 
that sets up a virtual Python environment. Ignas has contributed some 
work in that direction.

JW pointed the following out to me the other day, though: isolating 
Grok's python from the system Python might make life harder for 
beginners. If they install some useful Python package using easy_install 
or, say, the Ubuntu package manager, they would expect it to be 
available in their grok application and might be surprised if it's not. 
The proper way to add dependencies would be to modify setup.py and/or 
the buildout.cfg, but we may not want to confront beginners with a new 
world of dependency management right away as well.

Perhaps we can resolve this by giving grokproject an option. By default, 
it doesn't set up a virtual Python. However, if a certain option is 
used, we do. We put in the instructions that if they have problems 
installing or using Grok, they could try grokproject with the latter 
option (and spell out the causes and consequences).

> A more general impression: while Grok has clear goals and a clear
> audience, I feel like Zope 3 has always had an identity crisis.  But
> Grok puts Zope 3 in its place.  Grok establishes that Grok is a
> framework while Zope 3 is an integrated set of libraries.  Grok adds to
> Zope 3 the kind of stuff required to compete with popular frameworks
> like Rails or Django.  That's the way things seem to be headed, anyway.

Yes, that is the goal. We want Grok to be a Zope 3 that makes life 
easier for beginners, and makes experienced developers think less. Zope 
3 gives you a huge toolbox with randomly assorted tools that often you 
don't really know what they do. Very powerful and flexible tools. That's 
great if you're an expert, but it often very confusing if you're not. 
Grok tries to present the tools in a more integrated, easy to use manner 
that cover 90% of the use cases. The big toolbox that can tackle the 
last 10% is still there. And it's great that it is, as those 10% of use 
cases tend to be the ones that come back and bite you in the end.



More information about the Grok-dev mailing list