nedbat / coveragepy Goto Github PK

Originally reported by Danek Duvall (Bitbucket: dhduvall, GitHub: dhduvall)

When you have two lines of identical indentation, except that one uses spaces and the other uses tabs (eight spaces to a tabstop), then the tokenize module raises an IndentationError which coverage doesn't catch.

This can be considered a bug in the indentation, but it's only a style bug, as the code works just fine.

This could be considered a bug in tokenize, but I assume it's unlikely to get fixed.

It's a bit of a pain to fix in coverage, I think, because you're seeing it in the looping expression of a for loop. The loop would have to be restructured to pull the tokens from the generator inside the loop, inside a try/except, and either error out usefully (with filename and line number!) or try to go on. Still, it might not be too bad.

The attached file demonstrates the problem.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/31
• This issue had attachments: testindent.py. See the original issue for details.

This code has an anomaly:

# In this function, "for e in info" seems to have 2 branches:
def branches_2():
    if x: 
        for e in info: 
            print(1)
    else: 
        print(2)

# In this function, "for e in info" seems to have 3 branches:
def branches_3():
    for y in a: 
        if x:
            for e in info: 
                print(1)
        else: 
            print(2)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/39

From Gerard Petersen:

When I run an html report (with version 3.2) it tells me it covered 100% when it actually did not. The header of the code report file in question:

Coverage for myapp/views : 100%
514 statements 513 run 0 excluded 1 missing

Roundup wise this is absolutely correct, but technically it isn't. It also says 100% in the overview report (index.html).

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/41

Originally reported by Anonymous

The html output does not translate tab characters in the html output, so most browsers ignore it.
I believe this can be fixed by inserting around line 151 of html.py:
.replace("\t", "  ")

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/6

Originally reported by rozza (Bitbucket: rozza, GitHub: rozza)

CodeUnit fails with eggs as the files aren't actually available for reading.

Patch included

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/25
• This issue had attachments: codeunit.patch. See the original issue for details.

Originally reported by schafer (Bitbucket: schafer, GitHub: schafer)

The following file contents will produce an empty coverage report (create directory "testsub" first):

• import os
• print "statement 1"
• os.chdir("testsub")
• print "statement 2"

Issue tested and exists in both 3.01 and 2.80-2 (current for Ubuntu 9.04 repository).

Workaround: specify an absolute file location via COVERAGE_FILE. This provides correct output in 3.01, but not in 2.80-2.

Adjusting the .coverage filename to include an absolute path via something like filename = os.path.join( os.path.abspath( os.path.split(filename)[0]), os.path.split(filename)[1]) would probably resolve.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/24

Originally reported by Anonymous

If I download the current repository and run all the tests, I get one failure:

======================================================================
FAIL: test/farm/run/run_timid.py

Traceback (most recent call last):
File "/users/geoff/lib64/python/nose-0.11.0-py2.4.egg/nose/case.py", line 183, in runTest
self.test(*self.arg)
File "/users/geoff/bin/coverage.clean/test/test_farm.py", line 67, in call
execfile(self.runpy, glo)
File "run_timid.py", line 25, in ?
File "/users/geoff/bin/coverage.clean/test/test_farm.py", line 239, in contains
assert s in text, "Missing content in %s: %r" % (filename, s)
AssertionError: Missing content in out/showtraceout.txt: 'regular None'
-------------------- >> begin captured stdout << ---------------------
regular coverage.collector.PyTracer
timid coverage.collector.PyTracer

--------------------- >> end captured stdout << ----------------------

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/22

$ coverage -e
$ coverage -r
Traceback (most recent call last):
  File "c:\Python25\Scripts\coverage-script.py", line 8, in <module>
    load_entry_point('coverage==3.0b2', 'console_scripts', 'coverage')()
  File "c:\ned\coverage\trunk\coverage\cmdline.py", line 169, in main
    return CoverageScript().command_line(sys.argv[1:])
  File "c:\ned\coverage\trunk\coverage\cmdline.py", line 156, in command_line
    reporter.report(args, omit_prefixes=omit)
  File "c:\ned\coverage\trunk\coverage\summary.py", line 21, in report
    max_name = max(5, max(map(lambda cu: len(cu.name), self.code_units)))
ValueError: max() arg is an empty sequence

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/3

Originally reported by Gary Bernhardt (Bitbucket: garybernhardt, GitHub: garybernhardt)

The following file reports that only one of the two branches were followed. Since I'm calling it both ways, I'd expect it to report both! :)

#!python

def foo(a_list):
    try:
        a_list[0]
    except IndexError:
        pass

foo([])
foo([0])

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/35

Originally reported by eduardo schettino (Bitbucket: schettino72, GitHub: schettino72)

I am trying to use coverage r172 using python 2.4.

When I try to generate a report I get:

#!sh
$ coverage -r xxxc
Name             Stmts   Exec  Cover
------------------------------------
xxxc  tokenize.TokenError: ('EOF in multi-line statement', (104, 0))

if i ignore the error with:

#!sh
$ coverage -i -r xxxc 
Name             Stmts   Exec  Cover
------------------------------------

I don't get anything at all.

It works with coverage 2.85.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/5

If you use "coverage run xyzzy.py" and xyzzy.py isn't found, the exception shows stack frames from coverage.py itself:

C:\ned\coverage\trunk> coverage run xyzzy.py
Traceback (most recent call last):
  File "c:\Python25\Scripts\coverage-script.py", line 8, in <module>
    load_entry_point('coverage==3.0.1', 'console_scripts', 'coverage')()
  File "C:\ned\coverage\trunk\coverage\cmdline.py", line 504, in main
    return CoverageScript().command_line(sys.argv[1:])
  File "C:\ned\coverage\trunk\coverage\cmdline.py", line 388, in command_line
    self.run_python_file(args[0], args)
  File "C:\ned\coverage\trunk\coverage\execfile.py", line 35, in run_python_file
    source = open(filename, 'rU').read()
IOError: [Errno 2] No such file or directory: 'xyzzy.py'

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/23

Originally reported by Danek Duvall (Bitbucket: dhduvall, GitHub: dhduvall)

Currently, the --omit processing code specifically looks for glob characters because of limitations of the Windows shell. That said, if you want to omit a module by its name alone, rather than its full path, then you can't do something like

    coverage html --omit */cherrypy

If you let the (unix) shell expand that, the expansion may very well fail, preventing the command from running at all. If you escape the glob character from the shell so that it gets passed into coverage raw, then it will attempt to expand that the way the shell does, and will fail the same way.

It would be useful to use fnmatch to filter out patterns, instead of (or in addition to, depending on the argument) startswith().

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/34

Julian (http://somethinkodd.com/oddthinking) reports:

On my project, I put the test cases for foo.py in foo.test.py. I don't know why I do this; it is just what my predecessor did.

In this case, in the HTML index page, clicking on the foo.py line takes you to the foo.test.py coverage instead.

If I rename the test cases to foo_test.py, it functions perfectly, and is quite an eye-opener to the amount of code never executed.

(This bug-report can be filed under "If it hurts when you do that, then don't do that," but I thought I would let you know.)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/46

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

I tried to install the latest coverage on Windows using the Windows installer, but on running it just got a stack trace saying "No module named pkg_resources". I happened to know that that meant I needed to install setuptools, mostly because I'd already been through this process on Linux, but I guess many people wouldn't.

Even then it wasn't trivial either because there is still no Windows installer for setuptools with Python 2.6. A bit of googling got me there in the end, but maybe some notes on your website explaining this would save future Windows users some time.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/18

Originally reported by eduardo schettino (Bitbucket: schettino72, GitHub: schettino72)

It would be nice to have a color output for "coverage annotate" to be used on the shell.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/42

Originally reported by Anonymous

I am attempting to install coverage version 3.1 under Python 2.6.3 on a RHEL 5.3 machine. Setuptools version 0.6c9 is installed as well. No matter which way I try, easy_install or the conventional Python module install, I get the following output.

-bash-3.2$ python setup.py install
running install
running bdist_egg
running egg_info
writing coverage.egg-info/PKG-INFO
writing top-level names to coverage.egg-info/top_level.txt
writing dependency_links to coverage.egg-info/dependency_links.txt
writing entry points to coverage.egg-info/entry_points.txt
reading manifest file 'coverage.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching 'test'
writing manifest file 'coverage.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-i686/egg
running install_lib
running build_py
running build_ext
Traceback (most recent call last):
  File "setup.py", line 105, in <module>
    **more_setup_args
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/install.py", line 76, in run
  File "build/bdist.linux-i686/egg/setuptools/command/install.py", line 96, in do_egg_install
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/bdist_egg.py", line 174, in run
  File "build/bdist.linux-i686/egg/setuptools/command/bdist_egg.py", line 161, in call_command
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/install_lib.py", line 20, in run
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/command/install_lib.py", line 113, in build
    self.run_command('build_ext')
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/build_ext.py", line 46, in run
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "build/bdist.linux-i686/egg/setuptools/command/build_ext.py", line 175, in build_extension
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/command/build_ext.py", line 460, in build_extension
    ext_path = self.get_ext_fullpath(ext.name)
  File "/home/agrimstr/ACSPython/lib/python2.6/distutils/command/build_ext.py", line 633, in get_ext_fullpath
    filename = self.get_ext_filename(modpath[-1])
  File "build/bdist.linux-i686/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename
KeyError: 'tracer'

Line 105 from setup.py reads as follows:

Extension("coverage.tracer", sources=["coverage/tracer.c"])

I've removed the "coverage." and the build runs without error. I've changed "coverage.tracer" to "coverage/tracer" and it also builds without error. However, the resulting tracer.so ends up in different locations each time.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/27

1. Create a .coveragerc file with [run]parallel=True

2. Run tests with "coverage run"

3. Combine the data files with "coverage combine"

4. Run "coverage report". Nothing is displayed.

Reported by Ben Bangert

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/49

Originally reported by shauncutts (Bitbucket: shauncutts, GitHub: Unknown)

say we have test1.py such as:

#!python
# from peak.util.addons import AddOn

def foo():
  print "bar"

foo()

Now, if I run coverage on this

#!shell
> coverage -e -x test.py
> coverage -r test.py
Name    Stmts   Exec  Cover
---------------------------
test        3      3   100%

it works fine. However, with the first "include" line uncommented, it breaks:

#!shell
> coverage -e -x test.py
> coverage -r test.py
Name    Stmts   Exec  Cover
---------------------------
test        4      1    25%

If coverage is being run by nosetests, then it reports 0 coverage for all modules after the first one with an "addons" include.

-- Shaun

PS -- Great tool, by the way. I'd try to do more diagnosis if I weren't in the middle of a coding grind.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/13

Originally reported by Anonymous

When I run coverage (in this case, using ‘nosetests --with-cover’), statistics are collected and reported for the ‘coverage’ package itself, with is not useful:

coverage.collector 80 4 5% 3-139, 146-169

It's (ideally) out of my control what modules are imported by coverage itself. Instead, this information should not be reported by default, or should not be collected in the first place.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/8

Originally reported by Ben Finney (Bitbucket: bignose, GitHub: bignose)

Several functions in Coverage use string manipulation directly on filesystem paths. This should be done instead using the abstractions provided in the os.path module.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/44
• This issue had attachments: coveragepy.version-3.2.use-os-path-module.r627.patch. See the original issue for details.

Originally reported by Anonymous

Problem that happens with previous versions too - when it tries to generate a report for a file in a .egg package (zip file) it errors:

[dbr@schism:~/code/tvnamer]$ coverage html -d htmlcoverage/
Traceback (most recent call last):
  File "/usr/local/bin/coverage", line 8, in <module>
    load_entry_point('coverage==3.1b1', 'console_scripts', 'coverage')()
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/cmdline.py", line 558, in main
    return CoverageScript().command_line(sys.argv[1:])
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/cmdline.py", line 467, in command_line
    directory=options.directory, **report_args)
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/control.py", line 322, in html_report
    morfs, directory=directory, omit_prefixes=omit_prefixes)
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/html.py", line 70, in report
    self.report_files(self.html_file, morfs, directory, omit_prefixes)
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/report.py", line 54, in report_files
    report_fn(cu, statements, excluded, missing)
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/html.py", line 88, in html_file
    source = cu.source_file().read().expandtabs(4)
  File "/Library/Python/2.6/site-packages/coverage-3.1b1-py2.6-macosx-10.6-universal.egg/coverage/codeunit.py", line 128, in source_file
    return open(self.filename)
IOError: [Errno 20] Not a directory: '/Library/Python/2.6/site-packages/tvdb_api-1.1-py2.6.egg/cache.py'

Not a huge issue, as I don't usually need the report for the egg, so just do coverage html -d blah *.py or similar

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/26

    source_file, stmts, excluded, missed, missed_display = coverage.analysis2(module)
  File "C:\Python24\Lib\site-packages\coverage\__init__.py", line 44, in <lambda>
    return lambda *a, **kw: call_singleton_method(name, a, kw)
  File "C:\Python24\Lib\site-packages\coverage\__init__.py", line 31, in call_singleton_method
    return getattr(the_coverage, name)(*args, **kwargs)
  File "C:\Python24\Lib\site-packages\coverage\control.py", line 104, in analysis2
    st, ex, m, mf = self.analyze(code_unit)
  File "C:\Python24\Lib\site-packages\coverage\control.py", line 142, in analyze
    execed = self.data.executed_lines(filename)
  File "C:\Python24\Lib\site-packages\coverage\data.py", line 112, in executed_lines
    return self.executed[filename]
KeyError: 'e:\\lehrhaus\\project\\apps\\financial\\models\\discount.py'

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/2

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

I have set $COVERAGE_FILE to a global location in my shell startup script. On running the tests with "make tests" quite a few of them failed and I got strange information added to my global coverage file. When I unset the variable they work, of course...

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/15

Originally reported by Danek Duvall (Bitbucket: dhduvall, GitHub: dhduvall)

See the attached file. The first continuation character is accounted for correctly in the html output, but the other two are not, making it rather difficult to figure out what's going on in the rest of the file.

phys_tokens() makes this behavior explicit, so there's presumably some specific reason for this, but I don't understand why.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/30
• This issue had attachments: test.py. See the original issue for details.

Originally reported by Anonymous

Im running python 2.4 (CentOS 5.x build) with setuptools 0.6c9

when im trying to install coverage with:

#!sh

easy_install coverage

i got:

Searching for coverage
Reading http://pypi.python.org/simple/coverage/
Reading http://nedbatchelder.com/code/modules/coverage.html
Reading http://nedbatchelder.com/code/coverage
Best match: coverage 3.0
Downloading http://pypi.python.org/packages/source/c/coverage/coverage-3.0.tar.gz#md5=aba99cde68916bd3c8c41c8bb874f68b
Processing coverage-3.0.tar.gz
error: Not a recognized archive type: /tmp/easy_install-7C2dtz/coverage-3.0.tar.gz

i also got an error when im trying to install coverage with a setup.py

#!python

setup(
    ...
    tests_require = ['coverage==2.85'],
)



#!sh

./setup.py test



...
Searching for coverage==2.85
Reading http://cheeseshop.python.org/pypi/coverage/
Reading http://nedbatchelder.com/code/coverage
Reading http://cheeseshop.python.org/pypi/coverage/3.0
No local packages or download links found for coverage==2.85
error: Could not find suitable distribution for Requirement.parse('coverage==2.85')

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/7

In http://bitbucket.org/ned/coveragepy/issue/14/o-option-no-longer-works-with-relative#comment-59772, <> asked for regex-style module omission.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/36

Originally reported by Anonymous

Hi,

I found here : https://software.sandia.gov/svn/public/tpl/coverage/branches/3.0.dev (referenced by https://software.sandia.gov/trac/acro/wiki/Development/Resources#TestCoverageAnalysis) an extended version of coverage.py module which support Cobertura output.
With this XML support, we could integrate Python coverage report analysis into tools like Hudson, Sonar...

Why not add it into the main trunk ;) ? (the license seems to still be in GPL...)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/21

Originally reported by fniessink (Bitbucket: fniessink, GitHub: fniessink)

The HTML report does not report on code units that are not relative to the invoked script.

This is inconvenient in the following setup:

src/
src/whatever.py
tests/
tests/my_testrunner.py
tests/some_unittest_invoked_by_testrunner.py

Invoking coverage as follows generates a coverage HTML report that does not include whatever.py:

cd tests; rm .coverage; coverage -x my_testrunner.py; coverage -b -d coverage.out

Invoking coverage as follows generates a coverage text report that does include whatever.py:

cd tests; rm .coverage; coverage -x my_testrunner.py; coverage -r

Removing the lines in report.py:Reporter.report_files() that skip code_units that are not relative fixes the issue for me. See attached patch.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/11
• This issue had attachments: diff.txt. See the original issue for details.

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

In coverage 2.* it always used to work to just write
coverage -o , even though the documentation said "-o" was for absolute path prefixes. I found this ability fairly useful as I have third-party code inside my source tree. Would it be possible to restore this functionality?

(I have a patch for this which I will attach shortly)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/14
• This issue had attachments: omitargs.patch. See the original issue for details.

Originally reported by charles.merriam (Bitbucket: charles.merriam, GitHub: Unknown)

Coverage.py fails when the last line on the source file does not end in a LF. This is a known exec() wart. Lines with just spaces in the last line do trigger this failure. Usually, people just a "LF" to be sure.

#!bash

(live_dectools)~/p/decorator_toolkit/dectools (master)$ coverage run test/test_all.py
Traceback (most recent call last):
  File "/home/chasm/.virtualenvs/live_dectools/bin/coverage", line 8, in <module>
    load_entry_point('coverage==3.2', 'console_scripts', 'coverage')()
  File "/home/chasm/.virtualenvs/live_dectools/lib/python2.6/site-packages/coverage-3.2-py2.6-linux-i686.egg/coverage/cmdline.py", line 590, in main
    status = CoverageScript().command_line(sys.argv[1:])
  File "/home/chasm/.virtualenvs/live_dectools/lib/python2.6/site-packages/coverage-3.2-py2.6-linux-i686.egg/coverage/cmdline.py", line 468, in command_line
    self.run_python_file(args[0], args)
  File "/home/chasm/.virtualenvs/live_dectools/lib/python2.6/site-packages/coverage-3.2-py2.6-linux-i686.egg/coverage/execfile.py", line 43, in run_python_file
    exec_function(source, filename, main_mod.__dict__)
  File "<exec_function>", line 2, in exec_function
  File "test/test_all.py", line 59
    
SyntaxError: invalid syntax

Branch cb8970df (bb) breaks coverage.py
Branch ccd69d1 (bb) does not break coverage.py
git://github.com/merriam/dectools

Hope you enjoyed Pycon. Loved your talk. email if you have questions; [email protected]

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/47

Originally reported by James Bennett (Bitbucket: ubernostrum, GitHub: ubernostrum)

Running coverage on the current tip of my application django-flashpolicies (see http://bitbucket.org/ubernostrum/django-flashpolicies/src/359248e9e4d4/), I get an odd report; coverage doesn't think that the entire view tests file is executing:

Name                                                                             Stmts   Exec  Cover   Missing
--------------------------------------------------------------------------------------------------------------
/Users/jbennett/dev/hg/personal/django-flashpolicies/flashpolicies/tests/views      36     25    69%   28-29, 41-45, 58-59, 72-73

Those lines in the view tests file //are// executing, however, as I can verify by dropping print statements or changing the assertions so that the tests will fail.

The lines reported as missed all have in common that they come immediately after calls to xml.dom.minidom.parseString, but I've no idea why that would cause a problem or whether it's really related.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/10

This is counter-intuitive. It'd be better (but not essential) for it to match people's perception, which is that an empty init.py has no executable lines.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/1

In the coverage report for Coverage, there are lines for:

build\bdist.win32\egg\simplejson\__init__  	
build\bdist.win32\egg\wsgi_xmlrpc\__init__  	

They each point to their own file (build_bdist.win32_egg_simplejson___init__.html for example), but the contents of the file are for a different source file. It starts with "Coverage for c:\ned\coverage\trunk\test_init_.py: 100%". test_init_.py is also in the report, and also says this at the top.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/4

At the very least, builtins vs. builtin needs to be dealt with, and there may be other issues as well. The tests should run try_execfile in Python as well, and compare the results.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/48

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

I collect coverage data on both Linux and Windows as there is a fair amount of code in my system that differs between these platforms. I would therefore like to be able to use the -c option to combine this data, but of course the problem is that the same files are referred to in different ways. I'd therefore suggest the concept of an "alternative current working directory" whereby I can tell the coverage tool that a certain location is to be considered as equivalent to the local source tree. This could then also be used for example to combine data collected by different users on equivalent source, even if it wasn't cross-platform.

I enclose a patch which achieves this via a -A option on the command line (note this patch also includes the fixes for bugs 14 and 16, so is a quick way to get everything at once)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/17
• This issue had attachments: alt-cwds.patch, altcwds.bundle, testcover.zip. See the original issue for details.

Originally reported by Anonymous

$ uname -a
Linux 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux

$ python2.4 -V
Python 2.4.6

==== To Recreate ====

#!bash
mkdir testsetup
wget http://peak.telecommunity.com/dist/ez_setup.py
sudo /usr/bin/python2.4 ./ez_setup.py 
sudo /usr/bin/easy_install-2.4 virtualenv
python2.4 /usr/bin/virtualenv --no-site-packages .
./bin/easy_install 'coverage>=2.85'

==== Output ====

...
Searching for coverage>=2.85
Reading http://pypi.python.org/simple/coverage/
Reading http://nedbatchelder.com/code/modules/coverage.html
Reading http://nedbatchelder.com/code/coverage
Best match: coverage 3.0.1
Downloading http://pypi.python.org/packages/source/c/coverage/coverage-3.0.1.tar.gz#md5=b299c33b169bd796a6186a1f0f42a7da
Processing coverage-3.0.1.tar.gz
error: Not a recognized archive type: /tmp/easy_install-e3Z3gA/coverage-3.0.1.tar.gz

python2.6 easy_install works just fine.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/20
• This issue had attachments: coverage-3.0.1-py2.4-linux-i686.egg. See the original issue for details.

From a comment on the coverage page:

It seems that the recursion limit statement does not work when executed in coverage 3.0, like in this sample code:

#!python

import sys
sys.setrecursionlimit(2500)
def add1(number = 0):
    number = number + 1
    if(number < 2000):add1(number) 
if __name__ == '__main__': 
    add1()

Thanks.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/9

Originally reported by kundert (Bitbucket: kundert, GitHub: Unknown)

The exit status of 'coverage run ..." is always 1 regardless of the exit status of the underlying python program. This can be seen in tcsh by running:

coverage run exit.py; echo $status

where exit.py consists only of:

exit(0)

This screws up the error reporting in my test scripts, which reports every test as failing if I use coverage analysis.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/50

Originally reported by cjulien (Bitbucket: cjulien, GitHub: cjulien)

Yes, this is stupid ;) , but when launching coverage html without any .coverage file created, coverage fail with an exception like this :

Traceback (most recent call last):
 File "/usr/bin/coverage", line 7, in ?
   sys.exit(
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/cmdline.py", line 572, in main
   status = CoverageScript().command_line(sys.argv[1:])
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/cmdline.py", line 480, in command_line
   self.coverage.html_report(
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/control.py", line 295, in html_report
   reporter.report(
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/html.py", line 48, in report
   self.index_file()
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/html.py", line 139, in index_file
   fhtml.write(index_tmpl.render(locals()))
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/templite.py", line 103, in render
   engine.execute(self.ops)
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/templite.py", line 123, in execute
   self.result += str(self.evaluate(args))
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/templite.py", line 145, in evaluate
   value = self.evaluate(pipes[0])
 File "/usr/lib/python2.4/site-packages/coverage-3.2b2-py2.4-linux-i686.egg/coverage/templite.py", line 156, in evaluate
   value = value[dot]
TypeError: unsubscriptable object

I made a simple workaround to continue to use it like this :

--- ned/coverage/templite.py	2009-11-20 15:35:53.000000000 +0100
+++ dev/coverage/templite.py	2009-11-20 15:36:52.000000000 +0100
@@ -152,7 +133,10 @@
                 try:
                     value = getattr(value, dot)
                 except AttributeError:
+		   try :
                     value = value[dot]
+		   except TypeError:
+		       return value
                 if hasattr(value, '__call__'):
                     value = value()
         else:

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/37

Originally reported by Larry Gilbert (Bitbucket: l2g, GitHub: l2g)

In modules that incorporate doctest tests, lines that are run by doctest are missed (and show up as "missed") by coverage.py.

(This could be a usage error, but I have not found any other references to this problem.)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/19

Originally reported by Batiste Bieler (Bitbucket: batiste, GitHub: batiste)

Hi,

Sorry in advance because it's probably not a bug in your software.

The prototype of my functions and imports are not reported as covered by in the report.

But the body of my functions if they are tested are said as covered. But not the imports at the top and the function declaration.

I am with a Django project here. And I have the latest version of coverage.

What could be wrong with my config?

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/45

Originally reported by Anonymous

I recently tried to measure coverage of a program that calls os.execvpe, essentially causing the process to be replaced by a different one. This did not record any coverage information at all.

The reason of course is that os.execvpe does not return, so there is no opportunity to call coverage.stop() and coverage.save() as is done if e.g. an exception is thrown. I'd suggest this method could be "monkey-patched" so that such code can be inserted before it.
(and also the other 7 os.exec* methods of course)

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/43
• This issue had attachments: execfunctions.bundle. See the original issue for details.

Originally reported by tcourbon (Bitbucket: tcourbon, GitHub: tcourbon)

I think all is in the (long) title.

Here is what at propose, for htmlfiles/pyfile.html :

  </table>
  </div>
+ <div id='footer'>
+     <div class='content'>
+         <p>
+             <a class='nav' href='./index.html'>Back to coverage report</a> - <a class='nav' href='{{__url__}}'>coverage.py v{{__version__}}</a>
+         </p>
+     </div>
+ </div>

  </body>
  </html>

Thank for the nice tool,
regards,
Thomas

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/38

Originally reported by Jeremy Whitlock (Bitbucket: whitlockjc, GitHub: whitlockjc)

The coverage report for my app shows a function's contents as executed but says the line declaring the function was not. Here is an example:

#!python
class Person(object):
    def __init__(self, name):
        self.name = name

    def speak(self, msg):
        print(msg)

and here is an example usage during my coverage process:

#!python
...
p = Person("Jeremy")
p.speak("I like coverage.py.")

While this is purely an example, the report would tell me that lines 3 and 6 executed but not lines 2 and 5. I just updated to the latest version and I get the same result. (I tried with 3.0.1 and 3.1.)

I'm also seeing global-level comments and imports not being shown as executed either. So if I have:

#!python
#
# -*-python-*-
#
"""This is where the database code goes."""

import os, sys

...

I end up with my report telling me lines 4-6 were not executed.

I've used this for a few Django-based projects before and never ran into problems like this and while it could be bad Python structure and/or user error, I figured this would be the place to start.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/28

Originally reported by David Malcolm (Bitbucket: dmalcolm, GitHub: dmalcolm)

Background: I'm attempting to package coverage for python 3 for Fedora

Issue:
setup.py has this conditional:

if sys.hexversion < 0x03000000:
    # In Py 2.x, use setuptools.
    # etc
else:
    # No setuptools yet for Py 3.x, so do without.
    from distutils.core import setup, Extension
    console_script = 'coverage3'
 
    more_setup_args = dict(
        scripts = [
            'scripts/coverage',
            ],
        )

Upon attempting to build coverage-3.1 from tarball using python 3.1.1, this code fails in build_scripts with an error:
'scripts/coverage' does not exist

Looking at the coverage-3.1.tar.gz tarball, the "scripts" subdirectory isn't present.

I'm using Python 3.1.1 and notwithstanding the comment about "# No setuptools yet for Py 3.x, so do without.", the python 2 branch of the setup.py code seems to work fine with distribute-0.6.6 - assuming I invoke python3's 2to3 upon the source tree.

FWIW I patched this, and the result is a working python3-coverage RPM. See
https://bugzilla.redhat.com/show_bug.cgi?id=536948 and the patch here:
https://bugzilla.redhat.com/attachment.cgi?id=369109

The patch to setup.py removes most of the 2 vs 3 variation, to simply use the python2 code for both.

It also contains a fixup of console_script to vary, so that my /usr/bin/coverage is for python 2, and /usr/bin/coverage3 is for python 3 (so that both stacks are installable in parallel); you probably don't want that part of it in your version.

Hope this is helpful

Dave

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/29

Originally reported by Danek Duvall (Bitbucket: dhduvall, GitHub: dhduvall)

I'm having trouble with --omit. The code that we're testing is off in $PROTO, and the test suite itself is in the current directory, in directories "api" and "cli". So I'm running coverage as

    coverage html --omit $PROTO/mod1,$PROTO/mod2,api,cli

but that doesn't actually exclude api and cli from the report. I also tried with $PWD/api,$PWD/cli, but no dice.

In code_unit_factory(), we match cu.name against "prefix", but that prefix has been turned into an absolute pathname, so the .startswith() call doesn't return true, and we end up putting them into the final list.

If we check against cu.filename instead of cu.name, it appears to work correctly, but I'm not sure if that breaks something else.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/33

From Dirkjan Ochtman (hg dev):

BTW, I modified our coverage.py use to use the parallel files (with
the PID in the filename), but apparently the combination step leaves
behind the old files (leading some people to complain about the disk
use). There wasn't anything in the code that I could use for this, as
far as I could see from a quick glance. Is that right? Might be a
useful option for a future release.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/40

Create an empty tg project, run the tests. controllers.py shows as not executed, though adding an assertion there proves that it is. Details in http://lists.idyll.org/pipermail/testing-in-python/2009-July/002077.html

Looks like DecoratorTools does some really funny stuff with the trace function and fumbles the coverage trace function in the process.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/12

@garybernhardt reports (in a tweet!): "garybernhardt @nedbat A file with just "class Foo:\n pass" has Branch=2. Feels like a bug; is it one?"

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/32

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

As all the modules in my code are over 97% coverage now, I find it helpful to have the report show percentages to 1 decimal place instead of to the nearest integer. I enclose a patch, including a "farm test (?)" which achieves this via the command line and "-D 1".

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/16
• This issue had attachments: decimalplaces.patch, decimalplacesHTML.patch. See the original issue for details.