[Grok-dev] Issue when using grokproject on Debian Lenny

[Brandon Craig Rhodes]

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

  (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