Code coverage measurement for Python

Related tags

Django coveragepy
Overview

Coverage.py

Code coverage testing for Python.

Coverage.py measures code coverage, typically during test execution. It uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed.

Coverage.py runs on these versions of Python:

  • CPython 3.6 through 3.10 alpha.
  • PyPy3 7.3.3.

Documentation is on Read the Docs. Code repository and issue tracker are on GitHub.

New in 6.x: dropped support for Python 2.7 and 3.5.

For Enterprise

Tidelift Available as part of the Tidelift Subscription. Coverage and thousands of other packages are working with Tidelift to deliver one enterprise subscription that covers all of the open source you use. If you want the flexibility of open source and the confidence of commercial-grade software, this is for you. Learn more.

Getting Started

See the Quick Start section of the docs.

Change history

The complete history of changes is on the change history page.

Contributing

See the Contributing section of the docs.

Security

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

License

Licensed under the Apache 2.0 License. For details, see NOTICE.txt.

Comments
  • Process hang with Coverage 6.3

    Process hang with Coverage 6.3

    Describe the bug A clear and concise description of the bug.

    We've been having issues with our CI in GitHub Actions for the last few hours, and think it might be because of Coverage 6.3 - it's the one thing that's changed, and freezing it at 6.2 seems to allow runs to complete successfully.

    To Reproduce How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:

    1. What version of Python are you using? 3.7 seems to be a bit buggy with this. We also run 3.8 - 3.10 in CI and no issues seen with that.
    2. What version of coverage.py shows the problem? The output of coverage debug sys is helpful. 6.2.3
    3. What versions of what packages do you have installed? The output of pip freeze is helpful. See https://gist.github.com/tunetheweb/4d288ea4467ba74a66b3a0e2e8d5e4ea
    4. What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix. This is tricky. We run a lot of commands in CI, but checking out https://github.com/sqlfluff/sqlfluff/ and running tox -e py37 -- -n 2 test should reproduce it. Having problems setting up a 3.7 environment but will try to get a better test case. We do use a multithreaded process and noticed some changes to that.
    5. What commands did you run?

    Expected behavior A clear and concise description of what you expected to happen.

    Additional context Add any other context about the problem here.

    Will try to get a better repo.

    bug fixed concurrency 
    opened by tunetheweb 74
  • sqlite3.OperationalError: disk I/O error - coverage/sqldata.py, line 1024

    sqlite3.OperationalError: disk I/O error - coverage/sqldata.py, line 1024

    Describe the bug Since coverage v5.0.2, I throw an exception during Python 3.6 testing (Python 3.4, 3.5, 3.7, and 3.8 work fine - source). Below is a screenshot of the exception thrown (source) Screenshot from 2020-01-06 16-05-07

    This problem does not occur with v5.0.1 (source).

    Originally I thought this was a Travis CI issue (source), but it appears specific to the last release of coverage instead.

    To Reproduce How can we reproduce the problem? Please be specific.

    1. Python v3.6.7
    2. Ubuntu 16.04.6 LTS
    3. Kernel: 4.15.0-1028-gcp (xenial container here)
    4. v5.0.2 of coverage (pulled from PyPi/pip)
    5. The following packages are installed:
      apprise==0.8.2
      asgiref==3.2.3
      attrs==19.3.0
      certifi==2019.11.28
      chardet==3.0.4
      Click==7.0
      coverage==5.0.2
      Django==3.0.2
      entrypoints==0.3
      filelock==3.0.12
      flake8==3.7.9
      idna==2.8
      importlib-metadata==1.3.0
      Markdown==3.1.1
      mccabe==0.6.1
      mock==3.0.5
      more-itertools==8.0.2
      oauthlib==3.1.0
      packaging==20.0
      pluggy==0.13.1
      py==1.8.1
      pycodestyle==2.5.0
      pyflakes==2.1.1
      pyparsing==2.4.6
      pytest==5.3.2
      pytest-cov==2.8.1
      pytest-django==3.7.0
      pytz==2019.3
      PyYAML==5.3
      requests==2.22.0
      requests-oauthlib==1.3.0
      six==1.13.0
      sqlparse==0.3.0
      toml==0.10.0
      tox==3.14.3
      urllib3==1.25.7
      virtualenv==16.7.9
      wcwidth==0.1.8
      zipp==0.6.0
      
    6. I'm trying to build my package Apprise API which I hadn't needed to build until of late. Here is the latest build status.
    7. The command ran was:
      coverage run --parallel -m pytest apprise_api
      

    Expected behavior Not to get an exception (or maybe it just needs to be gracefully caught since it's on an __exit__ call anyway)?

    Additional context If i re-run the Travis-CI runner on a previous Python 3.6 test runner that has passed (in the past), it fails on Python 3.6 (more details and screenshots explained here).

    bug not our bug 
    opened by caronc 63
  • Show who tests what

    Show who tests what

    Originally reported by andrea crotti (Bitbucket: andrea_crotti, GitHub: Unknown)


    I was just using the awesome HTML report to see my test coverage and I had the following thought.

    Wouldn't it be nice to be able to see easily what parts of the test suites are actually testing my code?

    I guess that these information is collected while doing the annotation, right?

    In this way we could actually see if the tests are actually good very easily, which is specially important when working with other people code.


    • Bitbucket: https://bitbucket.org/ned/coveragepy/issue/170
    enhancement report 
    opened by nedbat 49
  • Executed lines reported as missing in threads

    Executed lines reported as missing in threads

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


    I apologize for a cross post from http://stackoverflow.com/q/43991865/1653558 but it looks like this is a better place for the report

    I'm getting some low coverage numbers on script with threads activated with a run() method. It seems that the coverage module is unable to keep track of all hits. Here is the code that demonstrates the problem. Running it should produce 100% coverage, but I'm getting 71.

    #!python
    
    from threading import Thread
    
    class MyNestedThread(Thread):
            def run(self):
                    print("hello from the nested thread!")
    
    class MyThread(Thread):
            def run(self):
                    print("Hello from thread")
                    t = MyNestedThread()
                    t.start()
                    return
    
    if __name__ == '__main__':
            for i in range(3):
                    t = MyThread()
                    t.start()
    
    #!python
    
    
    Hello from thread
    hello from the nested thread!
    Hello from thread
    Hello from thread
    hello from the nested thread!
    hello from the nested thread!
    
    Name     Stmts   Miss  Cover
    ----------------------------
    foo.py      14      4    71%
    

    re-running 'coverage run foo.py' sometimes gives a different %, and even 100% on occasion.


    • Bitbucket: https://bitbucket.org/ned/coveragepy/issue/582
    bug 
    opened by nedbat 41
  • pytest and multiprocessing: CoverageException: Can't combine line data with arc dat

    pytest and multiprocessing: CoverageException: Can't combine line data with arc dat

    Originally reported by Samuel Colvin (Bitbucket: samuelcolvin, GitHub: samuelcolvin)


    I'm getting CoverageException: Can't combine line data with arc dat when using coverage with the pytest-cov pytest extension. I think this is similar to #399, but that issue is closed.

    Example failure on travis: https://travis-ci.org/samuelcolvin/arq/builds/148541711

    The test causing problems is using click's CliRunner, code here. The CLI command that's testing starts another process (using multiprocessing.Process) to run the worker which is what's causing the problem, if you prevent the worker process being started the exception doesn't occur.

    I tried changing the concurrency mode but it made no difference.

    To reproduce: clone, pip install -e . && pip install -r tests/requirements.txt, py.test --cov=arq.

    relevant bits of pip freeze:

    click==6.6
    coverage==4.2
    pytest==2.9.2
    pytest-cov==2.3.0
    

    Let me know if you need anymore information.


    • Bitbucket: https://bitbucket.org/ned/coveragepy/issue/512
    bug not our bug 
    opened by nedbat 40
  • ModuleNotFoundError: No module named 'django_project' when I used coverage run manage.py test

    ModuleNotFoundError: No module named 'django_project' when I used coverage run manage.py test

    The below issue is with Coverage version 5.0a7

    When trying to run test for my django project using coverage run manage.py test i get ModuleNotFoundError. This issue kept coming and i thought it was as a result of what was addressed here --> https://stackoverflow.com/questions/50378166/django-coverage-modulenotfounderror-no-module-named-django-extensions

    None of the recommendations worked, i downgraded my django version from 3.0 to 2.2 and the problem persisted. This issue was rectified by downgrading to coverage version 4.5

    Like i said, i only encountered this issue with coverage version 5.0a7

    With the below dependencies, coverage is working as expected

    λ pipenv run pip list
    Package          Version
    ---------------- -------
    asgiref              3.2.3
    coverage          4.5
    Django              2.2
    Pillow               6.2.1
    pip                   19.3.1
    psycopg2         2.8.4
    pytz                2019.3
    setuptools       41.4.0
    sqlparse         0.3.0
    wheel            0.33.6
    

    complete error log

    Traceback (most recent call last):
      File "manage.py", line 21, in <module>
        main()
      File "manage.py", line 17, in main
        execute_from_command_line(sys.argv)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\__init__.py", line 401, in execute_from_command_line
        utility.execute()
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\__init__.py", line 395, in execute
        self.fetch_command(subcommand).run_from_argv(self.argv)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\commands\test.py", line 23, in run_from_argv
        super().run_from_argv(argv)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\base.py", line 320, in run_from_argv
        parser = self.create_parser(argv[0], argv[1])
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\base.py", line 294, in create_parser
        self.add_arguments(parser)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\commands\test.py", line 44, in add_arguments
        test_runner_class = get_runner(settings, self.test_runner)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\test\utils.py", line 301, in get_runner
        test_runner_class = test_runner_class or settings.TEST_RUNNER
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 76, in __getattr__
        self._setup(name)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 63, in _setup
        self._wrapped = Settings(settings_module)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 142, in __init__
        mod = importlib.import_module(self.SETTINGS_MODULE)
      File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\importlib\__init__.py", line 126, in import_module
        return _bootstrap._gcd_import(name[level:], package, level)
      File "<frozen importlib._bootstrap>", line 978, in _gcd_import
      File "<frozen importlib._bootstrap>", line 961, in _find_and_load
      File "<frozen importlib._bootstrap>", line 936, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
      File "<frozen importlib._bootstrap>", line 978, in _gcd_import
      File "<frozen importlib._bootstrap>", line 961, in _find_and_load
      File "<frozen importlib._bootstrap>", line 936, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
      File "<frozen importlib._bootstrap>", line 978, in _gcd_import
      File "<frozen importlib._bootstrap>", line 961, in _find_and_load
      File "<frozen importlib._bootstrap>", line 948, in _find_and_load_unlocked
    ModuleNotFoundError: No module named 'newproject'
    
    bug fixed 
    opened by spaceofmiah 39
  • Race condition when saving data under multiple threads

    Race condition when saving data under multiple threads

    Originally reported by Anonymous


    I do not have a minimum repro for this issue yet, but we're seeing errors in our CI after upgrading coverage from 4.3.4 to 4.4b1 and 4.4.

    We have some tests running using rostest. Upon upgrading from coverage 4.3.4 on our CI server, we started seeing the following errors:

    Traceback (most recent call last):
      File "/tmp/tmpw8DgrF/src/app/test/integration/test_head_service.py", line 86, in <module>
        main()
      File "/tmp/tmpw8DgrF/src/app/test/integration/test_head_service.py", line 82, in main
        rostest.rosrun(PKG, NAME, TestHeadService)
      File "/opt/ros/indigo/lib/python2.7/dist-packages/rostest/__init__.py", line 148, in rosrun
        _stop_coverage([package])
      File "/opt/ros/indigo/lib/python2.7/dist-packages/rostest/__init__.py", line 227, in _stop_coverage
        _cov.stop()
      File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 899, in analysis
        f, s, _, m, mf = self.analysis2(morf)
      File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 920, in analysis2
        analysis = self._analyze(morf)
      File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 935, in _analyze
        self.get_data()
      File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 824, in get_data
        if self.collector.save_data(self.data):
      File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 382, in save_data
        covdata.add_lines(abs_file_dict(self.data))
      File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 377, in abs_file_dict
        return dict((abs_file(k), v) for k, v in iitems(d))
      File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 377, in <genexpr>
        return dict((abs_file(k), v) for k, v in iitems(d))
    

    It's possible this is a rostest issue too - I haven't dug down very deeply, but we're certain that this issue does not occur when using coverage 4.3.4 - only 4.4b1 and 4.4.

    The source code for the caller is found here. It looks like stop is being called from line 227 and then blowing up internally.

    Will post more info once I have it.

    Contact info: [email protected]


    • Bitbucket: https://bitbucket.org/ned/coveragepy/issue/581
    • This issue had attachments: repro.py. See the original issue for details.
    bug 
    opened by nedbat 35
  • [WIP] Initial toml support

    [WIP] Initial toml support

    Missing docstrings and tests at the moment. If this looks like the right idea I can start adding those.

    Example pyproject.toml:

    [tool.coverage.run]
    branch = true
    source = ["outcome", "tests/"]
    
    [tool.coverage.report]
    precision = 1
    exclude_lines = [
        "pragma: no cover",
        "abc.abstractmethod",
    ]
    

    Resolves #664

    opened by RazerM 34
  • Use forward slashes in relative paths on Windows

    Use forward slashes in relative paths on Windows

    Current Problem I'm running coverage for multiple Python versions on both Linux and Windows. They are all run on Gitlab, with the Windows tests using Python install on the host, and with the Linux tests using Docker. The paths of the build directories are not deterministic (may be picked up by multiple runners, existing or yet to exist) so I have relative_files = True .

    The Windows paths use \ instead of / which, if the coverage combination and reporting is done on Windows, results in a report with every source file twice, one for each separator, although the end result appears to be correct. If this is done on Linux, it fails entirely when trying to resolve the paths containing backslashes.

    Example Report

    Name                                           Stmts   Miss Branch BrPart  Cover
     --------------------------------------------------------------------------------
     exmpl\__about__.py                                 6      0      0      0   100%
     exmpl/__about__.py                                 6      0      0      0   100%
     exmpl/__init__.py                                298     11    138      5    95%
     exmpl\__init__.py                                298     11    138      5    95%
     exmpl/_logging.py                                 47      2     16      1    92%
     exmpl\_logging.py                                 47      2     16      1    92%
     exmpl/cli.py                                      55      0     28      0   100%
     exmpl\cli.py                                      55      0     28      0   100%
    etc...
    

    Describe the solution you'd like Source paths on Windows should use forward slashes in relative paths to allow result combination and final reporting to be done on Linux, and to clean up the report output when done on Windows.

    Describe alternatives you've considered Manually modifying the coverage results generated from coverage run.

    enhancement fixed 
    opened by inkychris 33
  • Option to output lcov.info format?

    Option to output lcov.info format?

    Originally reported by Matthew Crenshaw (Bitbucket: sgtsquiggs, GitHub: sgtsquiggs)


    So that we can use coverage.py with IDE plugins that read the standard lcov.info format and highlight covered/uncovered lines. Would be super great!


    • Bitbucket: https://bitbucket.org/ned/coveragepy/issue/587
    enhancement 
    opened by nedbat 32
  • coverage regression with Python 3.7 ?

    coverage regression with Python 3.7 ?

    I posted a question on Stackoverflow because the time for my tests running with coverage and Python 3.7 were about 8 times longer than with Python 3.5 and 3.6. Hoefling suggested I run the tests without coverage and times for testing were about the same for the different versions. Hoefling suggested that it might be a coverage regression and that I post an issue.

    opened by 0LL13 30
  • 7.0.2 breaks coverage report

    7.0.2 breaks coverage report

    Repro https://github.com/platformdirs/platformdirs/tree/aa671aaa97913c7b948567f4d9c77d4f98bfa134 Failing example https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737

    ---------- coverage: platform linux, python 3.11.1-final-0 -----------
    Name                                                                                                            Stmts   Miss Branch BrPart  Cover   Missing
    -----------------------------------------------------------------------------------------------------------------------------------------------------------
    //home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/__init__.py      60     60     10      0     0%   5-318
    //home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/android.py       66     66     30      0     0%   1-118
    //home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/api.py           79     79     76      0     0%   1-156
    //home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/unix.py          96     96     56      0     1%   1-179
    //home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/version.py        2      2      0      0     0%   3-4
    src/platformdirs/__init__.py                                                                                       60      2     10      2    94%   23, 25
    src/platformdirs/android.py                                                                                        66     23     30      0    72%   22, 27, 34, [39](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:40), [44](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:45), 49, 57-60, 67, 75-78, 106-115
    src/platformdirs/api.py                                                                                            79      2     76      0    99%   121, 131
    src/platformdirs/macos.py                                                                                          32     32     18      0     0%   1-62
    src/platformdirs/unix.py                                                                                           96      9     56      2    90%   154, 162-174
    src/platformdirs/windows.py                                                                                        96     96     [45](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:46)      0     0%   1-182
    -----------------------------------------------------------------------------------------------------------------------------------------------------------
    TOTAL                                                                                                             963    [46](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:47)7    [47](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:48)7      4    51%
    

    It must be related to path mapping.

    Still working example with earlier version https://github.com/platformdirs/platformdirs/actions/runs/3821177309/jobs/6500063137. I've fixed the main branch for now by moving to relative files https://github.com/platformdirs/platformdirs/commit/72f09fa1252651f20a1ed4ea0b2bbdc310d59dba

    bug needs triage 
    opened by gaborbernat 0
  • Coverage.py 7.0.2 reports fewer statements than 7.0.1 under Python 3.7

    Coverage.py 7.0.2 reports fewer statements than 7.0.1 under Python 3.7

    Describe the bug

    Twine's scheduled CI failed this morning, because the coverage percentage dropped below the threshold under Python 3.7 (GHA), with 1785 statements executed. The day before, it passed (GHA), with 1807 statements executed. There were no commits in between. The only difference that I'm aware of is the release of Coverage.py 7.0.2, but I don't see any red flags in the release notes.

    To Reproduce

    1. What version of Python are you using?

      3.7 and 3.8

    2. What version of coverage.py shows the problem? The output of coverage debug sys is helpful.

      7.0.2

    3. What versions of what packages do you have installed? The output of pip freeze is helpful.

      % .tox/py37/bin/pip freeze
       attrs==22.2.0
       bleach==5.0.1
       build==0.9.0
       certifi==2022.12.7
       charset-normalizer==2.1.1
       commonmark==0.9.1
       coverage==7.0.2
       docutils==0.19
       exceptiongroup==1.1.0
       idna==3.4
       importlib-metadata==6.0.0
       importlib-resources==5.10.2
       iniconfig==1.1.1
       jaraco.classes==3.2.3
       keyring==23.13.1
       more-itertools==9.0.0
       packaging==22.0
       pep517==0.13.0
       pkginfo==1.9.2
       pluggy==1.0.0
       pretend==1.0.9
       Pygments==2.14.0
       pytest==7.2.0
       pytest-socket==0.5.1
       readme-renderer==37.3
       requests==2.28.1
       requests-toolbelt==0.10.1
       rfc3986==2.0.0
       rich==13.0.0
       six==1.16.0
       tomli==2.0.1
       twine @ file:///Users/bhrutledge/Dev/twine/.tox/.tmp/package/35/twine-4.0.3.dev21%2Bg89fba32.d20230103.tar.gz
       typing_extensions==4.4.0
       urllib3==1.26.13
       webencodings==0.5.1
       zipp==3.11.0
      
    4. What code shows the problem?

      https://github.com/pypa/twine/tree/89fba32c3cf56ff6b02c691154b3de7faf7def04

    5. What commands did you run?

      I'm able to reproduce this locally by running tox -e py37 and changing the coverage requirement in deps (e.g. to coverage==7.0.1 and coverage<7).

    Expected behavior

    The number of executed statements should be the same as previous versions.

    Additional context

    There's no change in statements from Coverage.py 6.5.0 to 7.0.1; both report 1807.

    Also maybe worth noting that py37 has always seemed to be lower; py38 and greater seem to consistently execute 1856 statements, with no change across Coverage.py versions.

    bug needs triage 
    opened by bhrutledge 1
  • Add protocol for paths printed by xml/html subcommands

    Add protocol for paths printed by xml/html subcommands

    Currently, coverage xml/html report prints the path of the file written to stdout:

    py311: commands[4]> coverage xml -o /home/bernat/git/virtualenv/.tox/coverage.py311.xml
    Wrote XML report to /home/bernat/git/virtualenv/.tox/coverage.py311.xml
    py311: commands[5]> coverage html -d /home/bernat/git/virtualenv/.tox/py311/tmp/htmlcov --show-contexts --title virtualenv-py311-coverage
    Wrote HTML report to /home/bernat/git/virtualenv/.tox/py311/tmp/htmlcov/index.html
    

    It would be great if we'd prepend the file:/ protocol prefix to this path so these links are clickable from the modern terminal, like iTerm or wezterm. I'm ok if it requires a flag to enable this behavior, as I can add that flag to tox.

    See:

    • https://wezfurlong.org/wezterm/hyperlinks.html#implicit-hyperlinks
    • https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

    The file prefix enables integrated hyperlinks in all modern terminals.

    Perhaps a better and more complicated alternative would be to hide it behind an extra and use rich to print integrated hyperlinks - see https://www.willmcgugan.com/blog/tech/post/real-working-hyperlinks-in-the-terminal-with-rich whenever tty is detected; this would allow to avoid the file prefix and also enable it for coverage report.

    If you consider this feature out of scope for the core project, I'd request some way to achieve this via a plugin :blush:

    enhancement needs triage 
    opened by gaborbernat 0
  • report.omit not working with relative_files

    report.omit not working with relative_files

    When doing https://github.com/pypa/virtualenv/pull/2477 I noticed that with relative_files report.omit seems no longer active. See failing run https://github.com/pypa/virtualenv/actions/runs/3824948711/jobs/6507540653, while before turning relative files on here https://github.com/pypa/virtualenv/actions/runs/3821105582/jobs/6499921063 seems to still work.

    The config file is here: https://github.com/gaborbernat/virtualenv/blob/fix/pyproject.toml#L96-L112

    bug 
    opened by gaborbernat 2
  • Although statements in subprocess get executed, coverage still reports them as missing.

    Although statements in subprocess get executed, coverage still reports them as missing.

    Describe the bug In my flask project, running through pytest with the pytest-flask plugin, a subprocess gets started. I get two .coverage..* files that get generated, but the report shows lines as missing. If I run the same tests on a debugger and set a breakpoint there, those lines are hit... but still report missing.

    UPDATE: There is one of the methods on a specific file in which a single line is reported missing (out of 5). I have checked the plugin starting the subprocess, (pytest-flask, file live_server.py) and it sends a SIGINT to the process before calling the join (which seems to be aligned with coverage recommendations).

    To Reproduce How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:

    1. What version of Python are you using? 3.10.8
    2. What version of coverage.py shows the problem?
    -- sys -------------------------------------------------------
                   coverage_version: 7.0.1
                    coverage_module: ~/venv/lib/python3.10/site-packages/coverage/__init__.py
                             tracer: -none-
                            CTracer: available
               plugins.file_tracers: -none-
                plugins.configurers: -none-
          plugins.context_switchers: -none-
                  configs_attempted: .coveragerc
                       configs_read: ~/.coveragerc
                        config_file: ~/.coveragerc
                    config_contents: b"[run]\nbranch = true\nparallel = true\nconcurrency = multiprocessing\nsigterm = true\nomit =\n    backend/tests/*\n    backend/blueprints/test.py\n    backend/blueprints/checkout.py\n\n[report]\nfail_under = 90\nshow_missing = True\n\n# Regexes for lines to exclude from consideration\nexclude_lines =\n    # Have to re-enable the standard pragma\n    pragma: no cover\n\n    # Don't complain about missing debug-only code:\n    def __repr__\n    if self\\.debug\n\n    # Don't complain if non-runnable code isn't run:\n    if 0:\n    if __name__ == .__main__.:\n\n    # Don't complain about abstract methods, they aren't run:\n    @(abc\\.)?abstractmethod\n"
                          data_file: -none-
                             python: 3.10.8 (main, Nov  1 2022, 14:18:21) [GCC 12.2.0]
                           platform: Linux-6.0.12-arch1-1-x86_64-with-glibc2.36
                     implementation: CPython
                         executable: ~/venv/bin/python
                       def_encoding: utf-8
                        fs_encoding: utf-8
                                pid: 154712
                                cwd: ~
                               path: ~/venv/bin
                                     /usr/lib/python310.zip
                                     /usr/lib/python3.10
                                     /usr/lib/python3.10/lib-dynload
                                     ~/venv/lib/python3.10/site-packages
                        environment: HOME = ~
                       command_line: ~/venv/bin/coverage debug sys
                    sqlite3_version: 2.6.0
             sqlite3_sqlite_version: 3.40.0
                 sqlite3_temp_store: 0
            sqlite3_compile_options: ATOMIC_INTRINSICS=1, COMPILER=gcc-12.2.0, DEFAULT_AUTOVACUUM,
                                     DEFAULT_CACHE_SIZE=-2000, DEFAULT_FILE_FORMAT=4,
                                     DEFAULT_JOURNAL_SIZE_LIMIT=-1, DEFAULT_MMAP_SIZE=0, DEFAULT_PAGE_SIZE=4096,
                                     DEFAULT_PCACHE_INITSZ=20, DEFAULT_RECURSIVE_TRIGGERS,
                                     DEFAULT_SECTOR_SIZE=4096, DEFAULT_SYNCHRONOUS=2,
                                     DEFAULT_WAL_AUTOCHECKPOINT=1000, DEFAULT_WAL_SYNCHRONOUS=2,
                                     DEFAULT_WORKER_THREADS=0, ENABLE_COLUMN_METADATA, ENABLE_DBSTAT_VTAB,
                                     ENABLE_FTS3, ENABLE_FTS3_PARENTHESIS, ENABLE_FTS3_TOKENIZER, ENABLE_FTS4,
                                     ENABLE_FTS5, ENABLE_MATH_FUNCTIONS, ENABLE_RTREE, ENABLE_STMTVTAB,
                                     ENABLE_UNLOCK_NOTIFY, HAVE_ISNAN, MALLOC_SOFT_LIMIT=1024, MAX_ATTACHED=10,
                                     MAX_COLUMN=2000, MAX_COMPOUND_SELECT=500, MAX_DEFAULT_PAGE_SIZE=8192,
                                     MAX_EXPR_DEPTH=10000, MAX_FUNCTION_ARG=127, MAX_LENGTH=1000000000,
                                     MAX_LIKE_PATTERN_LENGTH=50000, MAX_MMAP_SIZE=0x7fff0000,
                                     MAX_PAGE_COUNT=1073741823, MAX_PAGE_SIZE=65536, MAX_SQL_LENGTH=1000000000,
                                     MAX_TRIGGER_DEPTH=1000, MAX_VARIABLE_NUMBER=250000, MAX_VDBE_OP=250000000,
                                     MAX_WORKER_THREADS=8, MUTEX_PTHREADS, SECURE_DELETE, SYSTEM_MALLOC,
                                     TEMP_STORE=1, THREADSAFE=1
    
    1. What versions of what packages do you have installed?
    attrs==22.2.0
    certifi==2022.12.7
    charset-normalizer==2.1.1
    click==8.1.3
    exceptiongroup==1.1.0
    Flask==2.2.2
    Flask-Cors==3.0.10
    Flask-Login==0.6.2
    Flask-SQLAlchemy==3.0.2
    Flask-WTF==1.0.1
    greenlet==2.0.1
    gunicorn==20.1.0
    idna==3.4
    iniconfig==1.1.1
    itsdangerous==2.1.2
    Jinja2==3.1.2
    MarkupSafe==2.1.1
    numpy==1.24.1
    packaging==22.0
    pluggy==1.0.0
    psycopg2==2.9.5
    pydot==1.4.2
    pyparsing==3.0.9
    pytest==7.2.0
    pytest-flask==1.2.0
    python-dotenv==0.21.0
    PyYAML==6.0
    requests==2.28.1
    six==1.16.0
    SQLAlchemy==1.4.45
    SQLAlchemy-Utils==0.39.0
    stripe==5.0.0
    tomli==2.0.1
    urllib3==1.26.13
    Werkzeug==2.2.2
    WTForms==3.0.1
    
    1. What code shows the problem? It is a private repo, I cannot share :-/
    2. What commands did you run?
    rm -f .coverage.*
    coverage run -m pytest
    coverage combine
    coverage report 
    

    Expected behavior I get the information related to the coverage of the statements run by the subprocess that is running the flask server.

    bug question 
    opened by flixman 2
  • Boolean option configuration via Pyproject.toml is case-sensitive

    Boolean option configuration via Pyproject.toml is case-sensitive

    Describe the bug When setting the branch flag to true in run options via a pyproject.toml, an error occurs when parsing the toml file if the boolean value casing is "True".

    Python Version: 3.11 in a Poetry venv Coverage.py Version: 7.0.1

    To Reproduce

    Create a pyproject.toml file with the following configuration option:

    [tool.coverage.run]
    branch = "True"
    

    Console Output:

    (dashboard-py3.11) PS C:\Users\**********\repos\dashboard> coverage run -m pytest   
    Couldn't read config file pyproject.toml: Option [tool.coverage.run]branch couldn't convert to a boolean: 'True'
    

    My full pyproject.toml:

    [tool.poetry]
    name = "dashboard"
    version = "0.1.0"
    description = ""
    authors = [<OMITTED>]
    readme = "README.md"
    
    [tool.poetry.dependencies]
    python = "^3.11"
    flask = "^2.2.2"
    flask-login = "^0.6.2"
    requests = "^2.28.1"
    pytest = "^7.2.0"
    python-dotenv = "^0.21.0"
    coverage = "^7.0.1"
    black = {extras = ["d"], version = "^22.12.0"}
    flask-sqlalchemy = "^3.0.2"
    flask-dance = {extras = ["sqla"], version = "^6.2.0"}
    blinker = "^1.5"
    pytest-flask-sqlalchemy = "^1.1.0"
    
    [tool.pytest.ini_options]
    testpaths = ["tests"]
    
    [tool.coverage.run]
    branch = "true"
    source = ["app"]
    
    
    [build-system]
    requires = ["poetry-core"]
    build-backend = "poetry.core.masonry.api"
    

    Expected behavior The configuration documentation states: "Coverage.py will read from pyproject.toml if TOML support is available . . . Environment variable expansion in values is available, but only within quoted strings, even for non-string values. " This indicates that Boolean values should be enclosed within quotes as a string since the TOML standard does not support native Boolean Types.

    In the documentation section below this pyproject.toml compatibility note titled "Syntax", it states: "Boolean values can be specified as on, off, true, false, 1, or 0 and are case-insensitive."

    Following these examples of using an all lowercase "true" does solve the problem and coverage will run perfectly fine; however, the documentation does indicate that it is case-insensitive and considering that the Python bool value True doesn't work, it may be counterintuitive at first to write true in this way.

    It is not so much a bug that prevents coverage from running but moreso a difference in the documentation that creates confusion. I do not know if this TOML case-sensitive parsing behavior is intended and the documentation fails to mention this pyproject.toml specific case, or if the parsing needs to be adjusted to match the current documentation of being case-insensitive.

    bug 
    opened by tyleretheridge 2
Releases(7.0.3)
  • 7.0.3(Jan 4, 2023)

    • Fix: when using pytest-cov or pytest-xdist, or perhaps both, the combining step could fail with assert row is not None using 7.0.2. This was due to a race condition that has always been possible and is still possible. In 7.0.1 and before, the error was silently swallowed by the combining code. Now it will produce a message “Couldn’t combine data file” and ignore the data file as it used to do before 7.0.2. Closes issue 1522.

    :arrow_right:  PyPI page: coverage 7.0.3. :arrow_right:  To install: python3 -m pip install coverage==7.0.3

    Source code(tar.gz)
    Source code(zip)
  • 7.0.2(Jan 2, 2023)

    • Fix: when using the [run] relative_files = True setting, a relative [paths] pattern was still being made absolute. This is now fixed, closing issue 1519.
    • Fix: if Python doesn’t provide tomllib, then TOML configuration files can only be read if coverage.py is installed with the [toml] extra. Coverage.py will raise an error if TOML support is not installed when it sees your settings are in a .toml file. But it didn’t understand that [tools.coverage] was a valid section header, so the error wasn’t reported if you used that header, and settings were silently ignored. This is now fixed, closing issue 1516.
    • Fix: adjusted how decorators are traced on PyPy 7.3.10, fixing issue 1515.
    • Fix: the coverage lcov report did not properly implement the --fail-under=MIN option. This has been fixed.
    • Refactor: added many type annotations, including a number of refactorings. This should not affect outward behavior, but they were a bit invasive in some places, so keep your eyes peeled for oddities.
    • Refactor: removed the vestigial and long untested support for Jython and IronPython.

    :arrow_right:  PyPI page: coverage 7.0.2. :arrow_right:  To install: python3 -m pip install coverage==7.0.2

    Source code(tar.gz)
    Source code(zip)
  • 7.0.1(Dec 23, 2022)

    • When checking if a file mapping resolved to a file that exists, we weren’t considering files in .whl files. This is now fixed, closing issue 1511.
    • File pattern rules were too strict, forbidding plus signs and curly braces in directory and file names. This is now fixed, closing issue 1513.
    • Unusual Unicode or control characters in source files could prevent reporting. This is now fixed, closing issue 1512.
    • The PyPy wheel now installs on PyPy 3.7, 3.8, and 3.9, closing issue 1510.

    :arrow_right:  PyPI page: coverage 7.0.1. :arrow_right:  To install: python3 -m pip install coverage==7.0.1

    Source code(tar.gz)
    Source code(zip)
  • 7.0.0(Dec 18, 2022)

  • 7.0.0b1(Dec 3, 2022)

    A number of changes have been made to file path handling, including pattern matching and path remapping with the [paths] setting (see [paths]). These changes might affect you, and require you to update your settings.

    (This release includes the changes from 6.6.0b1

    , since 6.6.0 was never released.)

    • Changes to file pattern matching, which might require updating your configuration:
      • Previously, * would incorrectly match directory separators, making precise matching difficult. This is now fixed, closing issue 1407.
      • Now ** matches any number of nested directories, including none.
    • Improvements to combining data files when using the [run] relative_files setting, which might require updating your configuration:
      • During coverage combine, relative file paths are implicitly combined without needing a [paths] configuration setting. This also fixed issue 991.
      • A [paths] setting like */foo will now match foo/bar.py so that relative file paths can be combined more easily.
      • The [run] relative_files setting is properly interpreted in more places, fixing issue 1280.
    • When remapping file paths with [paths], a path will be remapped only if the resulting path exists. The documentation has long said the prefix had to exist, but it was never enforced. This fixes issue 608, improves issue 649, and closes issue 757.
    • Reporting operations now implicitly use the [paths] setting to remap file paths within a single data file. Combining multiple files still requires the coverage combine step, but this simplifies some single-file situations. Closes issue 1212 and issue 713.
    • The coverage report command now has a --format= option. The original style is now --format=text, and is the default.
      • Using --format=markdown will write the table in Markdown format, thanks to Steve Oswald, closing issue 1418.
      • Using --format=total will write a single total number to the output. This can be useful for making badges or writing status updates.
    • Combining data files with coverage combine now hashes the data files to skip files that add no new information. This can reduce the time needed. Many details affect the speed-up, but for coverage.py’s own test suite, combining is about 40% faster. Closes issue 1483.
    • When searching for completely un-executed files, coverage.py uses the presence of __init__.py files to determine which directories have source that could have been imported. However, implicit namespace packages don’t require __init__.py. A new setting [report] include_namespace_packages tells coverage.py to consider these directories during reporting. Thanks to Felix Horvat for the contribution. Closes issue 1383 and issue 1024.
    • Fixed environment variable expansion in pyproject.toml files. It was overly broad, causing errors outside of coverage.py settings, as described in issue 1481 and issue 1345. This is now fixed, but in rare cases will require changing your pyproject.toml to quote non-string values that use environment substitution.
    • An empty file has a coverage total of 100%, but used to fail with --fail-under. This has been fixed, closing issue 1470.
    • The text report table no longer writes out two separator lines if there are no files listed in the table. One is plenty.
    • Fixed a mis-measurement of a strange use of wildcard alternatives in match/case statements, closing issue 1421.
    • Fixed internal logic that prevented coverage.py from running on implementations other than CPython or PyPy (issue 1474).
    • The deprecated [run] note setting has been completely removed.

    :arrow_right:  PyPI page: coverage 7.0.0b1. :arrow_right:  To install: python3 -m pip install coverage==7.0.0b1

    Source code(tar.gz)
    Source code(zip)
  • 6.6.0b1(Oct 31, 2022)

    (Note: 6.6.0 final was never released. These changes are part of 7.0.0b1

    .)

    • Changes to file pattern matching, which might require updating your configuration:
      • Previously, * would incorrectly match directory separators, making precise matching difficult. This is now fixed, closing issue 1407.
      • Now ** matches any number of nested directories, including none.
    • Improvements to combining data files when using the [run] relative_files setting:
      • During coverage combine, relative file paths are implicitly combined without needing a [paths] configuration setting. This also fixed issue 991.
      • A [paths] setting like */foo will now match foo/bar.py so that relative file paths can be combined more easily.
      • The setting is properly interpreted in more places, fixing issue 1280.
    • Fixed environment variable expansion in pyproject.toml files. It was overly broad, causing errors outside of coverage.py settings, as described in issue 1481 and issue 1345. This is now fixed, but in rare cases will require changing your pyproject.toml to quote non-string values that use environment substitution.
    • Fixed internal logic that prevented coverage.py from running on implementations other than CPython or PyPy (issue 1474).

    :arrow_right:  PyPI page: coverage 6.6.0b1. :arrow_right:  To install: python3 -m pip install coverage==6.6.0b1

    Source code(tar.gz)
    Source code(zip)
  • 6.5.0(Sep 30, 2022)

    • The JSON report now includes details of which branches were taken, and which are missing for each file. Thanks, Christoph Blessing. Closes issue 1425.
    • Starting with coverage.py 6.2, class statements were marked as a branch. This wasn’t right, and has been reverted, fixing issue 1449. Note this will very slightly reduce your coverage total if you are measuring branch coverage.
    • Packaging is now compliant with PEP 517, closing issue 1395.
    • A new debug option --debug=pathmap shows details of the remapping of paths that happens during combine due to the [paths] setting.
    • Fix an internal problem with caching of invalid Python parsing. Found by OSS-Fuzz, fixing their bug 50381.

    :arrow_right:  PyPI page: coverage 6.5.0. :arrow_right:  To install: python3 -m pip install coverage==6.5.0

    Source code(tar.gz)
    Source code(zip)
  • 6.4.4(Aug 16, 2022)

  • 6.4.3(Aug 6, 2022)

    • Fix a failure when combining data files if the file names contained glob-like patterns. Thanks, Michael Krebs and Benjamin Schubert.
    • Fix a messaging failure when combining Windows data files on a different drive than the current directory, closing issue 1428. Thanks, Lorenzo Micò.
    • Fix path calculations when running in the root directory, as you might do in a Docker container. Thanks Arthur Rio.
    • Filtering in the HTML report wouldn’t work when reloading the index page. This is now fixed. Thanks, Marc Legendre.
    • Fix a problem with Cython code measurement, closing issue 972. Thanks, Matus Valo.

    :arrow_right:  PyPI page: coverage 6.4.3. :arrow_right:  To install: python3 -m pip install coverage==6.4.3

    Source code(tar.gz)
    Source code(zip)
  • 6.4.2(Jul 12, 2022)

    • Updated for a small change in Python 3.11.0 beta 4: modules now start with a line with line number 0, which is ignored. This line cannot be executed, so coverage totals were thrown off. This line is now ignored by coverage.py, but this also means that truly empty modules (like __init__.py) have no lines in them, rather than one phantom line. Fixes issue 1419.
    • Internal debugging data added to sys.modules is now an actual module, to avoid confusing code that examines everything in sys.modules. Thanks, Yilei Yang.

    :arrow_right:  PyPI page: coverage 6.4.2. :arrow_right:  To install: python3 -m pip install coverage==6.4.2

    Source code(tar.gz)
    Source code(zip)
  • 6.4.1(Jun 2, 2022)

    • Greatly improved performance on PyPy, and other environments that need the pure Python trace function. Thanks, Carl Friedrich Bolz-Tereick (pull 1381 and pull 1388). Slightly improved performance when using the C trace function, as most environments do. Closes issue 1339.
    • The conditions for using tomllib from the standard library have been made more precise, so that 3.11 alphas will continue to work. Closes issue 1390.

    :arrow_right:  PyPI page: coverage 6.4.1. :arrow_right:  To install: python3 -m pip install coverage==6.4.1

    Source code(tar.gz)
    Source code(zip)
  • 6.4(May 22, 2022)

    • A new setting, [run] sigterm, controls whether a SIGTERM signal handler is used. In 6.3, the signal handler was always installed, to capture data at unusual process ends. Unfortunately, this introduced other problems (see issue 1310). Now the signal handler is only used if you opt-in by setting [run] sigterm = true.
    • Small changes to the HTML report:
      • Added links to next and previous file, and more keyboard shortcuts: [ and ] for next file and previous file; u for up to the index; and ? to open/close the help panel. Thanks, J. M. F. Tsang.
      • The time stamp and version are displayed at the top of the report. Thanks, Ammar Askar. Closes issue 1351.
    • A new debug option debug=sqldata adds more detail to debug=sql, logging all the data being written to the database.
    • Previously, running coverage report (or any of the reporting commands) in an empty directory would create a .coverage data file. Now they do not, fixing issue 1328.
    • On Python 3.11, the [toml] extra no longer installs tomli, instead using tomllib from the standard library. Thanks Shantanu.
    • In-memory CoverageData objects now properly update(), closing issue 1323.

    :arrow_right:  PyPI page: coverage 6.4. :arrow_right:  To install: python3 -m pip install coverage==6.4

    Source code(tar.gz)
    Source code(zip)
  • 6.3.3(May 13, 2022)

  • 6.3.2(Feb 20, 2022)

    • Fix: adapt to pypy3.9’s decorator tracing behavior. It now traces function decorators like CPython 3.8: both the @-line and the def-line are traced. Fixes issue 1326.
    • Debug: added pybehave to the list of coverage debug and --debug options.
    • Fix: show an intelligible error message if --concurrency=multiprocessing is used without a configuration file. Closes issue 1320.

    :arrow_right:  PyPI page: coverage 6.3.2. :arrow_right:  To install: python3 -m pip install coverage==6.3.2

    Source code(tar.gz)
    Source code(zip)
  • 6.3.1(Feb 2, 2022)

    • Fix: deadlocks could occur when terminating processes. Some of these deadlocks (described in issue 1310) are now fixed.
    • Fix: a signal handler was being set from multiple threads, causing an error: “ValueError: signal only works in main thread”. This is now fixed, closing issue 1312.
    • Fix: --precision on the command-line was being ignored while considering --fail-under. This is now fixed, thanks to Marcelo Trylesinski.
    • Fix: releases no longer provide 3.11.0-alpha wheels. Coverage.py uses CPython internal fields which are moving during the alpha phase. Fixes issue 1316.

    :arrow_right:  PyPI page: coverage 6.3.1. :arrow_right:  To install: python3 -m pip install coverage==6.3.1

    Source code(tar.gz)
    Source code(zip)
  • 6.3(Jan 25, 2022)

    • Feature: Added the lcov command to generate reports in LCOV format. Thanks, Bradley Burns. Closes issues 587 and 626.
    • Feature: the coverage data file can now be specified on the command line with the --data-file option in any command that reads or writes data. This is in addition to the existing COVERAGE_FILE environment variable. Closes issue 624. Thanks, Nikita Bloshchanevich.
    • Feature: coverage measurement data will now be written when a SIGTERM signal is received by the process. This includes https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Process.terminate, and other ways to terminate a process. Currently this is only on Linux and Mac; Windows is not supported. Fixes issue 1307.
    • Dropped support for Python 3.6, which reached end-of-life on 2021-12-23.
    • Updated Python 3.11 support to 3.11.0a4, fixing issue 1294.
    • Fix: the coverage data file is now created in a more robust way, to avoid problems when multiple processes are trying to write data at once. Fixes issues 1303 and 883.
    • Fix: a .gitignore file will only be written into the HTML report output directory if the directory is empty. This should prevent certain unfortunate accidents of writing the file where it is not wanted.
    • Releases now have MacOS arm64 wheels for Apple Silicon, fixing issue 1288.

    :arrow_right:  PyPI page: coverage 6.3. :arrow_right:  To install: python3 -m pip install coverage==6.3

    Source code(tar.gz)
    Source code(zip)
  • 6.2(Nov 27, 2021)

    • Feature: Now the --concurrency setting can now have a list of values, so that threads and another lightweight threading package can be measured together, such as --concurrency=gevent,thread. Closes issue 1012 and issue 1082.
    • Fix: A module specified as the source setting is imported during startup, before the user program imports it. This could cause problems if the rest of the program isn’t ready yet. For example, issue 1203 describes a Django setting that is accessed before settings have been configured. Now the early import is wrapped in a try/except so errors then don’t stop execution.
    • Fix: A colon in a decorator expression would cause an exclusion to end too early, preventing the exclusion of the decorated function. This is now fixed.
    • Fix: The HTML report now will not overwrite a .gitignore file that already exists in the HTML output directory (follow-on for issue 1244).
    • API: The exceptions raised by Coverage.py have been specialized, to provide finer-grained catching of exceptions by third-party code.
    • API: Using suffix=False when constructing a Coverage object with multiprocessing wouldn’t suppress the data file suffix (issue 989). This is now fixed.
    • Debug: The coverage debug data command will now sniff out combinable data files, and report on all of them.
    • Debug: The coverage debug command used to accept a number of topics at a time, and show all of them, though this was never documented. This no longer works, to allow for command-line options in the future.

    :arrow_right:  PyPI page: coverage 6.2. :arrow_right:  To install: python3 -m pip install coverage==6.2

    Source code(tar.gz)
    Source code(zip)
  • 6.1.2(Nov 11, 2021)

    • Python 3.11 is supported (tested with 3.11.0a2). One still-open issue has to do with exits through with-statements.
    • Fix: When remapping file paths through the [paths] setting while combining, the [run] relative_files setting was ignored, resulting in absolute paths for remapped file names (issue 1147). This is now fixed.
    • Fix: Complex conditionals over excluded lines could have incorrectly reported a missing branch (issue 1271). This is now fixed.
    • Fix: More exceptions are now handled when trying to parse source files for reporting. Problems that used to terminate coverage.py can now be handled with [report] ignore_errors. This helps with plugins failing to read files (django_coverage_plugin issue 78).
    • Fix: Removed another vestige of jQuery from the source tarball (issue 840).
    • Fix: Added a default value for a new-to-6.x argument of an internal class. This unsupported class is being used by coveralls (issue 1273). Although I’d rather not “fix” unsupported interfaces, it’s actually nicer with a default value.

    :arrow_right:  PyPI page: coverage 6.1.2. :arrow_right:  To install: python3 -m pip install coverage==6.1.2

    Source code(tar.gz)
    Source code(zip)
  • 6.1.1(Oct 31, 2021)

    • Fix: The sticky header on the HTML report didn’t work unless you had branch coverage enabled. This is now fixed: the sticky header works for everyone. (Do people still use coverage without branch measurement!? j/k)
    • Fix: When using explicitly declared namespace packages, the “already imported a file that will be measured” warning would be issued (issue 888). This is now fixed.

    :arrow_right:  PyPI page: coverage 6.1.1. :arrow_right:  To install: python3 -m pip install coverage==6.1.1

    Source code(tar.gz)
    Source code(zip)
  • 6.1(Oct 30, 2021)

    • Deprecated: The annotate command and the Coverage.annotate function will be removed in a future version, unless people let me know that they are using it. Instead, the html command gives better-looking (and more accurate) output, and the report -m command will tell you line numbers of missing lines. Please get in touch if you have a reason to use annotate over those better options: mailto:[email protected].
    • Feature: Coverage now sets an environment variable, COVERAGE_RUN when running your code with the coverage run command. The value is not important, and may change in the future. Closes issue 553.
    • Feature: The HTML report pages for Python source files now have a sticky header so the file name and controls are always visible.
    • Feature: The xml and json commands now describe what they wrote where.
    • Feature: The html, combine, xml, and json commands all accept a -q/--quiet option to suppress the messages they write to stdout about what they are doing (issue 1254).
    • Feature: The html command writes a .gitignore file into the HTML output directory, to prevent the report from being committed to git. If you want to commit it, you will need to delete that file. Closes issue 1244.
    • Feature: Added support for PyPy 3.8.
    • Fix: More generated code is now excluded from measurement. Code such as attrs boilerplate, or doctest code, was being measured though the synthetic line numbers meant they were never reported. Once Cython was involved though, the generated .so files were parsed as Python, raising syntax errors, as reported in issue 1160. This is now fixed.
    • Fix: When sorting human-readable names, numeric components are sorted correctly: file10.py will appear after file9.py. This applies to file names, module names, environment variables, and test contexts.
    • Performance: Branch coverage measurement is faster, though you might only notice on code that is executed many times, such as long-running loops.
    • Build: jQuery is no longer used or vendored (issue 840 and issue 1118). Huge thanks to Nils Kattenbeck (septatrix) for the conversion to vanilla JavaScript in pull request 1248.

    :arrow_right:  PyPI page: coverage 6.1. :arrow_right:  To install: python3 -m pip install coverage==6.1

    Source code(tar.gz)
    Source code(zip)
  • 6.0.2(Oct 11, 2021)

    • Namespace packages being measured weren’t properly handled by the new code that ignores third-party packages. If the namespace package was installed, it was ignored as a third-party package. That problem (issue 1231) is now fixed.
    • Packages named as “source packages” (with source, or source_pkgs, or pytest-cov’s --cov) might have been only partially measured. Their top-level statements could be marked as un-executed, because they were imported by coverage.py before measurement began (issue 1232). This is now fixed, but the package will be imported twice, once by coverage.py, then again by your test suite. This could cause problems if importing the package has side effects.
    • The CoverageData.contexts_by_lineno() method was documented to return a dict, but was returning a defaultdict. Now it returns a plain dict. It also no longer returns negative numbered keys.

    :arrow_right:  PyPI page: coverage 6.0.2. :arrow_right:  To install: python3 -m pip install coverage==6.0.2

    Source code(tar.gz)
    Source code(zip)
  • 6.0.1(Oct 7, 2021)

    • In 6.0, the coverage.py exceptions moved from coverage.misc to coverage.exceptions. These exceptions are not part of the public supported API, CoverageException is. But a number of other third-party packages were importing the exceptions from coverage.misc, so they are now available from there again (issue 1226).
    • Changed an internal detail of how tomli is imported, so that tomli can use coverage.py for their own test suite (issue 1228).
    • Defend against an obscure possibility under code obfuscation, where a function can have an argument called “self”, but no local named “self” (pull request 1210). Thanks, Ben Carlsson.

    :arrow_right:  PyPI page: coverage 6.0.1. :arrow_right:  To install: python3 -m pip install coverage==6.0.1

    Source code(tar.gz)
    Source code(zip)
  • 5.5(Oct 7, 2021)

    • coverage combine has a new option, --keep to keep the original data files after combining them. The default is still to delete the files after they have been combined. This was requested in issue 1108 and implemented in pull request 1110. Thanks, Éric Larivière.
    • When reporting missing branches in coverage report, branches aren’t reported that jump to missing lines. This adds to the long-standing behavior of not reporting branches from missing lines. Now branches are only reported if both the source and destination lines are executed. Closes both issue 1065 and issue 955.
    • Minor improvements to the HTML report:
      • The state of the line visibility selector buttons is saved in local storage so you don’t have to fiddle with them so often, fixing issue 1123.
      • It has a little more room for line numbers so that 4-digit numbers work well, fixing issue 1124.
    • Improved the error message when combining line and branch data, so that users will be more likely to understand what’s happening, closing issue 803.

    :arrow_right:  PyPI page: coverage 5.5. :arrow_right:  To install: python3 -m pip install coverage==5.5

    Source code(tar.gz)
    Source code(zip)
  • 4.5.4(Oct 7, 2021)

  • 6.0(Oct 3, 2021)

    • The coverage html command now prints a message indicating where the HTML report was written. Fixes issue 1195.
    • The coverage combine command now prints messages indicating each data file being combined. Fixes issue 1105.
    • The HTML report now includes a sentence about skipped files due to skip_covered or skip_empty settings. Fixes issue 1163.
    • Unrecognized options in the configuration file are no longer errors. They are now warnings, to ease the use of coverage across versions. Fixes issue 1035.
    • Fix handling of exceptions through context managers in Python 3.10. A missing exception is no longer considered a missing branch from the with statement. Fixes issue 1205.
    • Fix another rarer instance of “Error binding parameter 0 - probably unsupported type.” (issue 1010).
    • Creating a directory for the coverage data file now is safer against conflicts when two coverage runs happen simultaneously (pull 1220). Thanks, Clément Pit-Claudel.

    :arrow_right:  PyPI page: coverage 6.0. :arrow_right:  To install: python3 -m pip install coverage==6.0

    Source code(tar.gz)
    Source code(zip)
  • 6.0b1(Oct 11, 2021)

    • Dropped support for Python 2.7, PyPy 2, and Python 3.5.
    • Added support for the Python 3.10 match/case syntax.
    • Data collection is now thread-safe. There may have been rare instances of exceptions raised in multi-threaded programs.
    • Plugins (like the Django coverage plugin) were generating “Already imported a file that will be measured” warnings about Django itself. These have been fixed, closing issue 1150.
    • Warnings generated by coverage.py are now real Python warnings.
    • Using --fail-under=100 with coverage near 100% could result in the self-contradictory message total of 100 is less than fail-under=100. This bug (issue 1168) is now fixed.
    • The COVERAGE_DEBUG_FILE environment variable now accepts stdout and stderr to write to those destinations.
    • TOML parsing now uses the tomli library.
    • Some minor changes to usually invisible details of the HTML report:
      • Use a modern hash algorithm when fingerprinting, for high-security environments (issue 1189). When generating the HTML report, we save the hash of the data, to avoid regenerating an unchanged HTML page. We used to use MD5 to generate the hash, and now use SHA-3-256. This was never a security concern, but security scanners would notice the MD5 algorithm and raise a false alarm.
      • Change how report file names are generated, to avoid leading underscores (issue 1167), to avoid rare file name collisions (issue 584), and to avoid file names becoming too long (issue 580).

    :arrow_right:  PyPI page: coverage 6.0b1. :arrow_right:  To install: python3 -m pip install coverage==6.0b1

    Source code(tar.gz)
    Source code(zip)
  • coverage-5.6b1(Apr 13, 2021)

    • Third-party packages are now ignored in coverage reporting. This solves a few problems:
      • Coverage will no longer report about other people’s code (issue 876). This is true even when using --source=. with a venv in the current directory.
      • Coverage will no longer generate “Already imported a file that will be measured” warnings about coverage itself (issue 905).
    • The HTML report uses j/k to move up and down among the highlighted chunks of code. They used to highlight the current chunk, but 5.0 broke that behavior. Now the highlighting is working again.
    • The JSON report now includes percent_covered_display, a string with the total percentage, rounded to the same number of decimal places as the other reports’ totals.
    Source code(tar.gz)
    Source code(zip)
  • coverage-5.5(Feb 28, 2021)

    • coverage combine has a new option, --keep to keep the original data files after combining them. The default is still to delete the files after they have been combined. This was requested in issue 1108 and implemented in pull request 1110. Thanks, Éric Larivière.
    • When reporting missing branches in coverage report, branches aren’t reported that jump to missing lines. This adds to the long-standing behavior of not reporting branches from missing lines. Now branches are only reported if both the source and destination lines are executed. Closes both issue 1065 and issue 955.
    • Minor improvements to the HTML report:
      • The state of the line visibility selector buttons is saved in local storage so you don’t have to fiddle with them so often, fixing issue 1123.
      • It has a little more room for line numbers so that 4-digit numbers work well, fixing issue 1124.
    • Improved the error message when combining line and branch data, so that users will be more likely to understand what’s happening, closing issue 803.
    Source code(tar.gz)
    Source code(zip)
  • coverage-5.4(Jan 26, 2021)

    • The text report produced by coverage report now always outputs a TOTAL line, even if only one Python file is reported. This makes regex parsing of the output easier. Thanks, Judson Neer. This had been requested a number of times (issue 1086, issue 922, issue 732).
    • The skip_covered and skip_empty settings in the configuration file can now be specified in the [html] section, so that text reports and HTML reports can use separate settings. The HTML report will still use the [report] settings if there isn’t a value in the [html] section. Closes issue 1090.
    • Combining files on Windows across drives now works properly, fixing issue 577. Thanks, Valentin Lab.
    • Fix an obscure warning from deep in the _decimal module, as reported in issue 1084.
    • Update to support Python 3.10 alphas in progress, including PEP 626: Precise line numbers for debugging and other tools.
    Source code(tar.gz)
    Source code(zip)
  • coverage-5.3.1(Dec 19, 2020)

    • When using --source on a large source tree, v5.x was slower than previous versions. This performance regression is now fixed, closing issue 1037.
    • Mysterious SQLite errors can happen on PyPy, as reported in issue 1010. An immediate retry seems to fix the problem, although it is an unsatisfying solution.
    • The HTML report now saves the sort order in a more widely supported way, fixing issue 986. Thanks, Sebastián Ramírez (pull request 1066).
    • The HTML report pages now have a Sleepy Snake favicon.
    • Wheels are now provided for manylinux2010, and for PyPy3 (pp36 and pp37).
    • Continuous integration has moved from Travis and AppVeyor to GitHub Actions.
    Source code(tar.gz)
    Source code(zip)
Owner
Ned Batchelder
Ned Batchelder
Example project demonstrating using Django’s test runner with Coverage.py

Example project demonstrating using Django’s test runner with Coverage.py Set up with: python -m venv --prompt . venv source venv/bin/activate python

Adam Johnson 5 Nov 29, 2021
The uncompromising Python code formatter

The Uncompromising Code Formatter “Any color you like.” Black is the uncompromising Python code formatter. By using it, you agree to cede control over

Python Software Foundation 30.7k Jan 3, 2023
Py-instant-search-redis - Source code example for how to build an instant search with redis in python

py-instant-search-redis Source code example for how to build an instant search (

Giap Le 4 Feb 17, 2022
A handy tool for generating Django-based backend projects without coding. On the other hand, it is a code generator of the Django framework.

Django Sage Painless The django-sage-painless is a valuable package based on Django Web Framework & Django Rest Framework for high-level and rapid web

sageteam 51 Sep 15, 2022
Strict separation of config from code.

Python Decouple: Strict separation of settings from code Decouple helps you to organize your settings so that you can change parameters without having

Henrique Bastos 2.3k Jan 4, 2023
based official code from django channels, replace frontend with reactjs

django_channels_chat_official_tutorial demo project for django channels tutorial code from tutorial page: https://channels.readthedocs.io/en/stable/tu

lightsong 1 Oct 22, 2021
Source code for Django for Beginners 3.2

The official source code for https://djangoforbeginners.com/. Available as an ebook or in Paperback. If you have the 3.1 version, please refer to this

William Vincent 10 Jan 3, 2023
Django Fett is an incomplete code generator used on several projects

Django Fett Django Fett is an incomplete code generator used on several projects. This is an attempt to clean it up and make it public for consumption

Jeff Triplett 6 Dec 31, 2021
Tweak the form field rendering in templates, not in python-level form definitions. CSS classes and HTML attributes can be altered.

django-widget-tweaks Tweak the form field rendering in templates, not in python-level form definitions. Altering CSS classes and HTML attributes is su

Jazzband 1.8k Jan 2, 2023
A django model and form field for normalised phone numbers using python-phonenumbers

django-phonenumber-field A Django library which interfaces with python-phonenumbers to validate, pretty print and convert phone numbers. python-phonen

Stefan Foulis 1.3k Dec 31, 2022
Stream Framework is a Python library, which allows you to build news feed, activity streams and notification systems using Cassandra and/or Redis. The authors of Stream-Framework also provide a cloud service for feed technology:

Stream Framework Activity Streams & Newsfeeds Stream Framework is a Python library which allows you to build activity streams & newsfeeds using Cassan

Thierry Schellenbach 4.7k Jan 2, 2023
Learn Python and the Django Framework by building a e-commerce website

The Django-Ecommerce is an open-source project initiative and tutorial series built with Python and the Django Framework.

Very Academy 275 Jan 8, 2023
Build reusable components in Django without writing a single line of Python.

Build reusable components in Django without writing a single line of Python. {% #quote %} {% quote_photo src="/project-hail-mary.jpg" %} {% #quot

Mitchel Cabuloy 277 Jan 2, 2023
Sampling profiler for Python programs

py-spy: Sampling profiler for Python programs py-spy is a sampling profiler for Python programs. It lets you visualize what your Python program is spe

Ben Frederickson 9.5k Jan 1, 2023
A django model and form field for normalised phone numbers using python-phonenumbers

django-phonenumber-field A Django library which interfaces with python-phonenumbers to validate, pretty print and convert phone numbers. python-phonen

Stefan Foulis 1.3k Dec 31, 2022
Python port of Google's libphonenumber

phonenumbers Python Library This is a Python port of Google's libphonenumber library It supports Python 2.5-2.7 and Python 3.x (in the same codebase,

David Drysdale 3.1k Jan 8, 2023
Faker is a Python package that generates fake data for you.

Faker is a Python package that generates fake data for you. Whether you need to bootstrap your database, create good-looking XML documents, fill-in yo

Daniele Faraglia 15.2k Jan 1, 2023
a little task queue for python

a lightweight alternative. huey is: a task queue (2019-04-01: version 2.0 released) written in python (2.7+, 3.4+) clean and simple API redis, sqlite,

Charles Leifer 4.3k Dec 29, 2022
Auto-detecting the n+1 queries problem in Python

nplusone nplusone is a library for detecting the n+1 queries problem in Python ORMs, including SQLAlchemy, Peewee, and the Django ORM. The Problem Man

Joshua Carp 837 Dec 29, 2022