Re: Cheetah test failure

From: "Mike Orr" <mso@xxxxxx>

> On Thu, Oct 02, 2003 at 03:31:42PM -0700, Robert Lilly wrote:
> > I just installed Cheetah and am following the User Guide. I got as far
> > as step 3.6 - Testing  your installation. Cheetah failed miserably. The
> > results are attached.
>
> For "ImportError: No module named temp", make sure you're running the
> test in a directory you have write permission in.  It wants to test
> writing a module and reading it back in.  I think there was another
> something to check for too when this happens but I don't remember what
> it is.  Maybe somebody else on the list remembers.  It was discussed
> within the past month, when somebody else had problems with the tests.

I'll do a search to find the discussion you mention. I'm running as
Administrator on Windows 2000, so I have write permission everywhere, so I
doubt that is an issue.

> "TypeError: update() takes exactly one argument (0 given)" is tricky
> to explain.  There's a bug in Cheetah that makes $update match a
> dictionary method rather than the variable it's supposed to match.
> The same thing happens with any variable with the same name as a
> dictionary method; e.g., $clear.  This test is skipped if you're
> using the C version of the NameMapper, so most ppl don't see the
> error.  But you are falling back to the Python version of the
> NameMapper, which means it can't load the C version.  I think I
> remember hearing that the C version doesn't work on Windows.
> Fixing this bug in both NameMapper versions is one of the main
> priorities for 1.0, but it has to wait till Tavis has time to do
> it.  In the meantime, ignore the error and don't use any $placeholder
> names that match dictionary method names.  (But $self.update should
> be OK, along with $something.update, etc.)

This is very helpful to know. I will make it a point to know the dictionary
method names so as not to use them as $placeholder names. Are there any
other key words or method names I should avoid using?

> 'AssertionError: Template output mismatch: ..." is because Python 2.3
> changed the behavior of boolean values, and the tests haven't been
> updated yet.  Ignore them.  In Python >= 2.3, str(1==1) and str(1==0)
> print print "True" and "False" respectively rather than "1" and "0".

Got it. Thanks for the historical insight. It sure helps talking to someone
who's got the inside track!

> "AssertionError: subcommand killed by signal 1: cheetah compile --flat
> child/a.tmpl" means what it says.  The subcommand failed for some
> reason.  Again, the current directory being not writable is the most
> likely culprit.  All those subcommand tests want to write files and
> create subdirectories.

Again, I don't think write permissions are applicable here. Perhaps the
tests were written to run on *nix systems and don't fully translate to the
Win32 platform. I will be setting Cheetah up on a Linux box soon, and will
see what kind of results I get with the tests on that platform.

> That should cover it.
>
> -- 
> -Mike Orr (aka. Sluggo)

I think so. This information, combined with the fact that Tavis says
everything seems to work fine in spite of those failure messages encourages
me to give it a go. I'll report back if I have problems in actual usage.


Thanks,

Robert



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf