[Grok-dev] Issue when using grokproject on Debian Lenny
Brandon Craig Rhodes
brandon at rhodesmill.org
Thu May 8 16:58:24 EDT 2008
ffm <ffm at intserverror.com> writes:
> I get lots of errors whenever I try to start a grok project.
For those of you who see things like this in the future, note that
there is really only one legitimate error message in all of the
horrible stuff that ffm got back from his attempt to install:
> src/zope/interface/_zope_interface_coptimizations.c:15:20: error: Python.h:
> No such file or directory
That's it! That's the whole story! Everything else listed was a
simple syntactical consequence of the missing header file(s).
It's a shame that C compilers hid such critical information way, way
up at the top of their output! While normal people writing C, of
course, learn the trick of looking at the top of the error messages
first, I wonder how many Python programmers - some of whom might not
even know about C, or know that C is being compiled under the hood -
we can expect to know the trick.
This brings up an issue I'd wanted to suggest: I think it's
frightening for normal developers that simple things like missing
templates produce Grok tracebacks. I think a special grok_developer
flag should be necessary to see the traceback from errors that our
code detects and understands. Why do I feel this way?
(1) Visually, I think that a traceback from inside of Grok's code
makes it look like Grok, itself, has failed and needs to be
(2) Therefore, if we detect an error and can simply print out "you
have a Foo view in app.py but no foo.pt template", then we
should; a traceback into Grok's correctly-working (!) code that
it executed to produce the error is irrelevant. Heck, even if
it *is* a bug in Grok that caused the message, the traceback is
probably irrelevant, since the bit grokking logic that went
wrong is probably long done by then! :-)
(3) The only real reason, in my opinion, to have an error produce a
traceback is if the traceback *includes the user's code*. If
their code, that called something that failed, is not going to
be anywhere in the traceback, we ought to suppress it by default.
Irrelevant tracebacks make us too much like Java products I've seen. :-)
Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon
More information about the Grok-dev