Hi! Just wanted to say that I'm using this package and I find it super useful - it's much better and less invasive than some of the other ones on GitHub/MELPA.

Do you have any plans to upload it on MELPA? Anything I can do to help?

This is a PR that combines a lot of stuff (mentioned in #6), so I'm not expecting it to be merged as is, but I thought I'd share at this point even if it's not quite ready. I have been using this for several months now and found it useful.

Also my elisp is probably pretty bad!

Basically 2 main features:

1. The ability to use the .coverage SQLite file directly, without needing the coverage.xml report to be generated, for normal overlay analysis. The SQLite file is less preferred, because the XML file contains processing done to handling empty lines and docstrings etc,. - analysis that could not easily be reproduced in elisp, it requires a Python parser.

   This requires using some internals of the coverage SQLite schema, and reproducing some of the "packing" logic for line numbers (see https://github.com/nedbat/coveragepy/blob/master/coverage/numbits.py ). However, we include version checking of the file, and if the schema changes in the future, we can add support for multiple schemas easily.

2. If --cov-context=test has been used, it adds the ability to find which tests executed which lines of code. This can only be implemented using the SQLite file, as the XML doesn't contain this info. The only user interface on this at the moment is the command python-coverage-rerun-pytest-current-region command, which is the only interface I needed. It basically allows you to put your cursor somewhere in the code, do M-x python-coverage-rerun-pytest-current-region and get a pytest command line for rerunning the tests that executed that code, like this:

pytest path/to/tests.py::test_1 path/to/tests.py::test_2 

This is super useful on some occasions!

A cool thing you can do with coverage and pytest-cov is dynamic contexts, which results in a neat feature in the HTML report, where you can see the tests that executed a line of code.

Obviously it would be cool to have this directly from my editor in some way. Seeing that this package is already overlapping with this functionality, I thought this might be a good place for it. Would you be interested in having a feature like that?

I'm aware it's a lot of work, so it's something I might tackle myself, before doing so I just wanted to know what your thoughts on that becoming part of this package. I'm not a brilliant elisp hacker but this is probably a good project for me to take on at my level, and it certainly scratches an itch for me.

There are some significant issues. The contexts data is not exported to coverage.xml as far as I can see, so that is a bit of a blocker.

However, another way to get the data is directly via the .coverage data file, which is an SQLite file (since version 5, 2018 - https://coverage.readthedocs.io/en/coverage-5.5/changes.html#version-5-0a2-2018-09-03). This file doesn't have a fixed schema, but it does have an easy way to check the schema version: select version from coverage_schema; So you know if it is different from what you expect and you can support multiple versions probably fairly easily for our needs.

If you switched to using the SQLite data directly, you get an additional advantage - there is no need to run coverage xml as an extra step first. There would probably be other advantages too in terms of more powerful querying of the data. It may also have performance benefits if you have a large .coverage file - using coverage.xml requires you to parse the whole XML file every time to get just the data you are interested. Would you be open to switching from coverage.xml parsing to using the SQLite file?

Thanks!

Currently this module uses absolute path to file. But this leads to missing files in case of virtualization. Basically I do have docker container that runs tests and absolute path differs from what this module tries to find.

I see 2 possible solutions to this:

• add alias-path or something like this variable to replace part of path so sources and system path matches
• use relative paths: find coverage.xml consider this folder as root for project and search files based on this

what do you think? I'm not advanced enough with elisp to do it myself :P (but I'll try it anyway, and will appreciate some hints)

When enabled, it sets the checker to python-coverage, and changes the style of flycheck. When disabled, restores flycheck's previous checker and style.

This is how it looks like: