[py-dev] Log to a file

[Simon]

On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev  
+ execnet-dev| wrote:

> On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote:
>> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py-
>> dev + execnet-dev| wrote:
>>
>>> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com>
>>> wrote:
>>>> Hi!
>>>>
>>>> I would like to capture the verbose output of test runs to a file
>>>> so that the debug is captured to a file regardless of whether the
>>>> test failed or when the test is not running to completion.
>>>>
>>>> Is there an easy way of doing this via a command line option, or
>>>> should I be perhaps modifying the resultlog plugin or something
>>>> similar?
>>>>
>>>> Thanks,
>>>>
>>>> Simon
>>>
>>> You know about py.test -s right?
>>>
>>> Cheers,
>>> fijal
>>
>> Sorry, I wasn't particularly clear.
>>
>> We generally run our tests with the -v option which is fine, which
>> produces a level of output suitable for our general day to day use.
>>
>> However we would also like to log the complete (-s) output to a file
>> in the background. So that if at some point in the future we need to
>> go through the detailed output, it is available.
>>
>> We'd also like this to happen in such a way that if the tests were to
>> hang or hard crash halfway through, we still have the debug log.
>>
>> Any ideas?
>
> I am not completely sure how to best implement it.  Maybe extend the
> "--capture" option to specify a filename.  A naive implementation  
> would
> only produce the test output though, not meta-information like test  
> name
> or traceback.  Maybe a bit tricky to get this working for dist- 
> testing like
> "-n 3" but that's probably true for any impl idea for this feature.
>
> what do you think?
>
> Capturing is done via code in the _py/test/plugin/pytest_capture.py  
> and
> in _py/io/capture.py (py-trunk references) - not completely trivial  
> code
> because it works hard to play nicely with tests/apps using the
> std logging module which assumes ownership of sys.stdout/stderr  
> stream.
> Do you feel like giving it a try?
>
> I plan for a 1.1 beta1 soon so it could be available soon.
>
> best,
> holger

Hi Holger,

I started looking into this a bit but ran into a problem when I  
started to probe the py.io module.

I tried running the py.io examples on the website <http://codespeak.net/py/dist/io.html 
 > but when I run the py.io.StdCaptureFD example, python dies on the  
second line:

stakita at okum:~$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
History restored: /auto/home/stakita/.pyhistory, Max Length: 500
 >>> import py, sys
 >>> capture = py.io.StdCaptureFD()
stakita at okum:~$

My guess is that an exception is being thrown, but the captured  
sys.stderr descriptor is not passing any meaningful traceback.

I tried wrapping the call in try/except, but that didn't seem to help.  
On the positive side, the problem appears to be quite reproducible.

Any ideas on what is going on here?

Regards,

Simon


Sysinfo:

stakita at okum:~$ uname -a
Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC  
2009 i686 GNU/Linux
stakita at okum:~$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
History restored: /auto/home/stakita/.pyhistory, Max Length: 500
 >>> import py
 >>> py.version
'1.0.2'