[qmtest] [PATCH] Add more annotations to QMTest runs

[Nathaniel Smith]

On Wed, Feb 11, 2004 at 01:18:20PM -0800, Mark Mitchell wrote:
> Nathaniel Smith wrote:
> >Questions:
> > - Currently the simple presence of qmtest.run.aborted signals an
> >   aborted run; should we instead always write this annotation with
> >   value either "True" or "False"?
> > 
> >
> I think your way is OK.  Is "True" how we normally spell it in QMTest?  
> (Check qm.fields.)  We should probably use a consistent spelling.

Oh, good point, I'd forgotten that we write out booleans in some
cases.  (We accept just about anything when reading booleans, in
qm.common.parse_boolean, so I just went for consistency with Python
booleans.)  I'll switch it to "true".

> > - Is there any documentation that should be added for these?  As far
> >   as I can tell, annotations aren't documentated at all ATM...
> >
> > 
> >
> That's probably true -- but you should fix that. :-)  Let's add a new 
> section in the manual somewhere.

Right.  It's a pre-existing problem, though; how about I file the bug
and commit this now?

> >+def get_username():
> >+    """Returns the current username as a string.
> >+
> >+    If the username cannot be found, raises a 'QMException'."""
> >+
> >+    # First try using the 'getpass' module.
> >+    try:
> >+        return getpass.getuser()
> >+    except:
> >+        pass
> >
> > 
> Do we actually know that getpass doesn't work on Windows?  The docs 
> don't suggest that.

It apparently works iff the user has the appropriate environment
variables set, which is common but not guaranteed.  At least, this is
the impression I got from various mailing list posts.

Basically, getpass on Windows works just like it does on Unix, but
without the fallback to looking things up in /etc/passwd; the win32api
call adds that fallback.

> >+    # 'getpass' doesn't necessarily work on Windows, so if that fails,
> >+    # try the win32 function.
> >+    try:
> >+        import win32api
> > 
> >
> I'm a little bit afraid that we could some how get here under UNIX, and 
> then try to import this module, which might cause weird things to 
> happen.  Perhaps we could assert that doesn't happen, or condition this 
> whole block on sys.platform the way we do elsewhere in QMTest?

We could get here under Unix, but it should just raise an ImportError;
using ImportErrors for runtime feature tests seems a fairly common
idiom in Python.  We could be more paranoid here, if you think it's
important, but I think it's unnecessary; "weird things" here means
"bugs in the interpreter".

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen