With relative_files = True, I'm still getting absolute paths in .coverage

[alex]

Describe the bug

I have a project configured to use relative_files = True: pyca/cryptography#5982, however I'm still ending up with some absolute paths in .coverage.

To Reproduce

• Python 3.8.5
• coverage 5.5
• Other relevant package: pytest-cov 2.11.1
• Code is github.com/alex/cryptography @ d73438c46210f37831a87f7757217d97caa6004d (this is presently the goofball-coverage-best-coverage branch)

To reproduce I ran: tox -e py38 -- tests/x509/ (this runs just one subdirectory of tests, that's all it takes to reproduce)

Then I looked at .coverage with `sqlite3:

sqlite> SELECT path from file limit 10;
tests/conftest.py
/home/alex/p/cryptography/src/cryptography/hazmat/backends/openssl/backend.py
tests/x509/__init__.py
tests/x509/test_ocsp.py
tests/x509/test_x509.py
/home/alex/p/cryptography/src/cryptography/hazmat/_der.py
/home/alex/p/cryptography/src/cryptography/utils.py
tests/hazmat/__init__.py
tests/hazmat/primitives/__init__.py
tests/hazmat/primitives/fixtures_dsa.py

Expected behavior

All paths are relative to pwd, meaning the /home/alex/p/cryptography/ prefix is not present.

[alex]

As additional context, the reason I noticed this is that it results in coverage xml producing a coverage.xml where all the lines in these files are hits="0". If I manually fix up .coverage with a UPDATE file SET path = substr(path, N) WHERE path LIKE '/home/%'; then I get the right output from coverage xml.

[alex]

I believe a contributing factor (though maybe not the root cause? I'm still learning my way around the codebase) is that PathAliases.map will always return an absolute path when it re-maps something: https://github.com/nedbat/coveragepy/blob/master/coverage/files.py#L413

This is then invoked when combining coverage data: https://github.com/nedbat/coveragepy/blob/master/coverage/sqldata.py#L594

[nedbat]

@alex thanks for the test case (though it was a bit of a challenge to get the tests going far enough to see the problem!)

And you were right about the root cause. This is fixed in 1a616da.

[alex]

Thanks Ned!