os.path.relpath fails when saving a coverage file with coverage 5 in a folder from a different Windows drive
See original GitHub issueDescribe the bug
In the scikit-learn test suite we have a test that launches a subprocess and the atexit registry triggers the saving of a coverage file in a tempfolder in d:\ while the current working directory has been changed by pytest --pyargs
to c:\ in the meantime.
E AssertionError: Error in atexit._run_exitfuncs:
E Traceback (most recent call last):
E File "c:\miniconda\envs\testvenv\lib\ntpath.py", line 562, in relpath
E path_drive, start_drive))
E ValueError: path is on mount 'D:', start on mount 'c:'
cmd = ['c:\\miniconda\\envs\\testvenv\\python.exe', 'C:\\Users\\VSSADM~1\\AppData\\Local\\Temp\\tmp32ajt78f_src_test_sklearn.py']
coverage_rc = None
cwd = 'c:\\miniconda\\envs\\testvenv\\lib\\site-packages'
...
I do not understand why the traceback starts at atexit._run_exitfuncs
and then goes to ntpath.relpath
directly without going through the function of the coverage
module. I suspect that the culprit is:
https://github.com/nedbat/coveragepy/blob/coverage-5.0/coverage/sqldata.py#L982
When rolling back to coverage 4.5.3, the problem disappears.
To Reproduce
This problems happens with coverage 5.0 and Python 3.7.5 with the latest pytest and pytest-cov.
It seems tricky to reproduce, in particular I do not understand why this only happens in the subprocess tests of scikit-learn and never in the main process itself. Maybe the current working directory is restored to the d:\ tempfolder prior to writing the coverage files?
Anyhow the details can be found in the CI logs of this pull request where I have patched the ntpath.relpath
function to display more debug info:
https://github.com/scikit-learn/scikit-learn/pull/15909
I will open a PR to fix the issue in coveragepy.
It looks similar to #824 but the error message is actually different.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:10 (10 by maintainers)
This is now available in coverage==5.0.1
awesome – thanks for the triage and fix on this! this is affecting pytest’s testsuite as well (it was quite a bit harder to track down in python3 as the stacktrace doesn’t mention coverage at all! fortunately our maintenance branch showed the failures in python2)
for completeness (and perhaps so others can find in google), here are the traces we saw:
2.x
3.x