Re: Testing with concurrent sessions

Markus Wanner <markus(at)bluegap(dot)ch> wrote:

> I must admit that I haven't ever tested on python 2.6 before. I'll
> try that (especially as it's the staircase to 3.0, IIUC).

I don't use python much, so I can't comment on that. I do see that
my system has these two versions on it, with a symlink that makes
2.6 the default.

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2

Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2

I haven't quite gotten it to work yet; I'll start over with 3.0 and
see how it goes. I'll also attach the results of the 2.6 attempt.

> Try a CursesReporter() instead, it gives much nicer output!

Thanks, I'll try it.

A few other issues in testing so far:

(1) I see that a 'make dcheck' does a 'make install'. That's not
right. For one thing I usually install in a location where I need
to sudo to install; but more importantly, I want to do all checks
*before* I install. It's easy enough to work around that for now,
but I don't think it's acceptable long-term.

(2) After a 'make dcheck' failure, the cluster created for the
testing is left running.

(3) If the install could check dependencies, report problems, and
refuse to install without required packages, that would be less
confusing for python novices (like me).

Perhaps some of these problems will go away with python 3.0, but I
figured I should pass the info along.

Thanks again for this. It should help me a lot.

-Kevin