[Grok-dev] Re: First Experience with Grok
faassen at startifact.com
Sun Sep 16 09:00:56 EDT 2007
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