File path not correct when using drive with subst in Windows

[fabioz]

To reproduce the issue, let's say you have a file structure such as:

c:\temp\somedir\test_it.py

with the contents:

def test_it():
    raise AssertionError(__file__)

then, do a subst for the c:\temp\somedir to T:

i.e.:

subst t: c:\temp\somedir

Then go to T: and run the test:

cd /D T:
python -m pytest test_it.py 

The output I have when running it with pytest 5.2.1 is:

 c:\bin\Python37-32\python.exe -m pytest test_it.py
================================ test session starts ================================ 
platform win32 -- Python 3.7.4, pytest-5.2.1, py-1.8.0, pluggy-0.13.0
rootdir: C:\temp\somedir
collected 1 item

test_it.py F                                                                   [100%]

===================================== FAILURES ====================================== 
______________________________________ test_it ______________________________________

    def test_it():
>       raise AssertionError(__file__)
E       AssertionError: C:\temp\somedir\test_it.py

C:\temp\somedir\test_it.py:3: AssertionError
================================= 1 failed in 0.03s =================================

whereas on pytest 5.0.1 it was correct (as shown below)

c:\bin\Python37-32\python.exe -m pytest test_it.py
================================ test session starts ================================ 
platform win32 -- Python 3.7.4, pytest-5.0.1, py-1.8.0, pluggy-0.13.0
rootdir: T:\
collected 1 item

test_it.py F                                                                   [100%]

===================================== FAILURES ====================================== 
______________________________________ test_it ______________________________________

    def test_it():
>       raise AssertionError(__file__)
E       AssertionError: T:\test_it.py

test_it.py:3: AssertionError
============================= 1 failed in 0.04 seconds ==============================

• output of pip list from the virtual environment you are using

c:\bin\Python37-32\python.exe -m pip list
Package            Version
------------------ ----------
astroid            2.3.1
atomicwrites       1.3.0
attrs              19.3.0
certifi            2019.9.11
colorama           0.4.1
importlib-metadata 0.23
isort              4.3.21
lazy-object-proxy  1.4.2
mccabe             0.6.1
more-itertools     7.2.0
packaging          19.2
pip                19.2.3
pipenv             2018.11.26
pluggy             0.13.0
py                 1.8.0
pylint             2.4.2
pyparsing          2.4.2
pytest             5.2.1
setuptools         40.8.0
six                1.12.0
typed-ast          1.4.0
virtualenv         16.7.5
virtualenv-clone   0.5.3
wcwidth            0.1.7
wrapt              1.11.2
zipp               0.6.0

• pytest and operating system versions

Pytest 5.2.1 has this issue. The regression was introduced in pytest 5.1.0 (i.e.: it works properly in pytest 5.0.1)

OS: Windows 10

[fabioz]

Another note: it seems that CPython 3.8 changed something else too, so, even older versions of pytest fail with CPython 3.8 (i.e.: it works with CPython 3.7 + pytest 5.0.1 but fails with CPython 3.8 and pytest 5.0.1 -- and pytest 5.2.1 fails with both).

[asottile]

just because I'm curious: what's the problem here?

[fabioz]

The problem is that pytest reports all errors as if they were run from C:\temp\somedir instead of T: in the example (i.e.: you can see in the output that it sees C:\temp\somedir as the rootdir instead of the working directory which would be T:).

This is an issue mainly when working with editors/IDEs where you work the file and then when you click the traceback it'll open the file as if it was a different file (i.e.: T:\test_it.py was run, but tracebacks will show C:\temp\somedir\test_it.py).

[adamkerz]

Likely caused by the same problem here: #5905

[fabioz]

I did some investigation and it appears that the issue is that pytest is now using Path().resolve() to resolve paths (including the current directory).

This means that the paths reported on a run become wrong (they're no longer reporting the current directory, they are reporting the resolved directory).

i.e.:

> c:
> cd \
> mkdir foo
> subst f: c:\foo
> python -c "import pathlib;print(pathlib.Path().resolve())"
  C:\foo
> python -c "import pathlib;print(pathlib.Path().absolute())"
  F:

So, given this, creating a file on F:\test_loc.py with the contents below:

def test_path_error_location():
    raise AssertionError()

The output when running it from F: is the following:

py.test test_loc.py
================================= test session starts ================================== 
platform win32 -- Python 3.7.6, pytest-5.3.2, py-1.8.1, pluggy-0.13.1
rootdir: C:\foo
collected 1 item

test_loc.py F                                                                     [100%]

======================================= FAILURES ======================================= 
_______________________________ test_path_error_location _______________________________

    def test_path_error_location():
>       raise AssertionError()
E       AssertionError

C:\foo\test_loc.py:2: AssertionError
================================== 1 failed in 0.03s ===================================

and when running from C:\foo is:

py.test test_loc.py
================================= test session starts ================================== 
platform win32 -- Python 3.7.6, pytest-5.3.2, py-1.8.1, pluggy-0.13.1
rootdir: C:\foo
collected 1 item

test_loc.py F                                                                     [100%]

======================================= FAILURES ======================================= 
_______________________________ test_path_error_location _______________________________

    def test_path_error_location():
>       raise AssertionError()
E       AssertionError

test_loc.py:2: AssertionError
================================== 1 failed in 0.02s ===================================

So, notice how in the examples above the error is reported at the full (wrong) path when running from F: and is reported with a relative (correct) path when run from C:\foo.

I think changing Path.resolve to Path.absolute should fix the issue. I'll provide a pull request shortly.

[fabioz]

Pull request: #6523

[fabioz]

There's another breaking change on Python 3.8:

Until Python 3.7 os.path.realpath = os.path.abspath on Windows, whereas on Python 3.8 os.path.realpath is resolving the links (which is the reason my pull request for Python 3.8 was failing).

See: https://bugs.python.org/issue9949

I just updated the pull request.