Handle Windows/Unix path separator differences in combine

[lazka]

Is your feature request related to a problem? Please describe.

I'm generating coverage data on Windows and Linux machines and want to combine them to a final html report. To get the different base paths sorted I use the new relative_path option which works nicely (except for #899), thanks for that!

The problem now is that the combine command doesn't merge "foo/bar/quux.py" with "foo\bar\quux.py" and as a result they get treated as separate files.

When I then try to generate a html report it complains that "foo\bar\quux.py" doesn't exist.

Describe the solution you'd like

I'd like that combine normalizes the path separators to "/" (which is valid on Windows as well) before trying to combine two reports or that the paths get normalized to "/" before being written to the sqlite DB.

Example Data

Here are two .coverage files for the same test run on Windows an Linux as an example:
coverage-example.zip

[lazka]

In case anyone is facing the same problem, here is a script to fix the files before combining:

import sys
import sqlite3

def main(argv):
    paths = argv[1:]

    for path in paths:
        # https://github.com/nedbat/coveragepy/issues/903
        conn = sqlite3.connect(path)
        conn.execute("UPDATE file set path = REPLACE(path, '\\', '/')")
        conn.commit()
        conn.close()

if __name__ == "__main__":
    sys.exit(main(sys.argv))

[greg-hellings]

Just ran into this problem myself. The script from @lazka worked flawlessly. Thanks!

[nedbat]

(Sorry this has gotten so stale...) Do you have a way to demonstrate the problem? When you use the [paths] setting, the path separators should be mapped together as you want.

[nedbat]

Feel free to re-open this if you can provide more information.

[lazka]

As they don't share a common prefix I don't know how I would use "[paths]". I tried some things (creating a dummy paths entry) but there was no change.

• Use coverage.zip
• Run coverage combine --keep
• Run sqlite3 .coverage "select * from file"
• See that the resulting coverage file contains duplicate entries for everything

@nedbat I don't have rights to re-open.