Regression: item.nodeid starts with '::' when symlinks are involved

[Lekensteyn]

Since upgrading from pytest 3.8.2 to 3.9.3 (and 3.10.0), one of my tests are failing because the nodeid has an additional ::. It seems related to symlinks. Reproducer with two files:

# tests/conftest.py
def pytest_collection_modifyitems(items):
    for item in items:
        print(item.nodeid)
        assert not item.nodeid.startswith('::')
        #name = item.nodeid.split("::")[0].replace(".py", "").replace("/", ".")
# tests/test_some.py
def test_some():
    pass

Working:

$ pytest -v tests/
platform linux -- Python 3.7.1, pytest-3.10.0, py-1.7.0, pluggy-0.8.0 -- /usr/bin/python
cachedir: .pytest_cache
rootdir: /tmp/bla, inifile:
plugins: xdist-1.24.0, forked-0.2
collecting ... tests/test_some.py::test_some
collected 1 item
tests/test_some.py::test_some PASSED

Not working (I was not able to reproduce it with a symlink at /tmp/foo or /tmp/bla/foo):

$ ln -s $PWD/tests ~/foo
$ pytest -v ~/foo
latform linux -- Python 3.7.1, pytest-3.10.0, py-1.7.0, pluggy-0.8.0 -- /usr/bin/python
cachedir: .pytest_cache
rootdir: /home/peter/foo, inifile:
plugins: xdist-1.24.0, forked-0.2
collecting ... ::test_some.py::test_some
...
INTERNALERROR> AssertionError: assert not True
INTERNALERROR>  +  where True = <built-in method startswith of str object at 0x7fbf2d5a54e0>('::')
INTERNALERROR>  +    where <built-in method startswith of str object at 0x7fbf2d5a54e0> = '::test_some.py::test_some'.startswith
INTERNALERROR>  +      where '::test_some.py::test_some' = <Function 'test_some'>.nodeid

Possibly related issues:
#4174 (I also encountered this issue with 3.9.1 and 3.9.2, but not 3.9.3).
#4108

[blueyed]

Thanks for the report.
Would be helpful if you could git-bisect this to some commit.

I suggest writing some test in e.g. testing/test_collection_new.py for this (look for existing ones in testing/test_collection.py). This would be good then already as a test for a fix, of course.

[blueyed]

Not working (I was not able to reproduce it with a symlink at /tmp/foo or /tmp/bla/foo):

$ ln -s $PWD/tests ~/foo
$ pytest -v ~/foo

Looks like it might be related to you being in ~.
I assume you could reproduce it with /tmp/foo when in /tmp.

Looks like it is related to removal of the current cwd somewhere wrongly.

[Lekensteyn]

I'll try to investigate it later. As quick note, this problem is not limited to collection, it also occurs with normal tests:

# /tmp/bla/test_nodeid.py
def test_nodeid(request):
    print(request.node.nodeid)
    assert not request.node.nodeid.startswith('::')

Working/non-working:

$ pytest -s
platform linux -- Python 3.7.1, pytest-3.10.0, py-1.7.0, pluggy-0.8.0
rootdir: /tmp/bla, inifile:
plugins: xdist-1.24.0, forked-0.2
collected 1 item                                                                                                                                                                            

test_nodeid.py test_nodeid.py::test_nodeid
.
$ ln -s /tmp/bla ~/foo
$ pytest -s ~/foo
...
../../home/peter/foo ::test_nodeid.py::test_nodeid
F

...
request = <FixtureRequest for <Function 'test_nodeid'>>

    def test_nodeid(request):
        print(request.node.nodeid)
>       assert not request.node.nodeid.startswith('::')
E       AssertionError: assert not True
E        +  where True = <built-in method startswith of str object at 0x7fdf7cd9e1c0>('::')
E        +    where <built-in method startswith of str object at 0x7fdf7cd9e1c0> = '::test_nodeid.py::test_nodeid'.startswith
E        +      where '::test_nodeid.py::test_nodeid' = <Function 'test_nodeid'>.nodeid
E        +        where <Function 'test_nodeid'> = <FixtureRequest for <Function 'test_nodeid'>>.node

test_nodeid.py:3: AssertionError

[blueyed]

Could reproduce it, caused by 7268462.

[blueyed]

Fixed by #4337.
Thanks for the report and details, and sorry for breaking it in the first place.. ;)

[Lekensteyn]

Thanks for the proposed fix, while the situation improves (there is no longer a leading ::), the nodeid is still different than 3.8.2 and before. Reproducer:

# /tmp/bla/test_nodeid.py
import unittest
import pytest

def test_nodeid(request):
    assert request.node.nodeid == 'test_nodeid.py::test_nodeid'

class TestCase(unittest.TestCase):
    @pytest.fixture(autouse=True)
    def __inject_request(self, request):
        self._fixture_request = request

    def test_ut(self):
        request = self._fixture_request
        assert request.node.nodeid == 'test_nodeid.py::TestCase::test_ut'

With pytest 3.10.0 + the _pytest/main.py patch:

$ cd /tmp/bla
$ pytest -s  # normal case
...
platform linux -- Python 3.7.1, pytest-3.10.0, py-1.7.0, pluggy-0.8.0
rootdir: /tmp/bla, inifile:
collected 2 items                                                                                                                                                          

test_nodeid.py ..
$ ln -s $PWD ~/foo
$ pytest -s ~/foo  # symlink case
platform linux -- Python 3.7.1, pytest-3.10.0, py-1.7.0, pluggy-0.8.0
rootdir: /home/peter/foo, inifile:
collected 2 items                                                                                                                                                          

../../home/peter/foo/bla/test_nodeid.py FF
...
    def test_nodeid(request):
>       assert request.node.nodeid == 'test_nodeid.py::test_nodeid'
E       AssertionError: assert 'bla/test_nod...::test_nodeid' == 'test_nodeid.py::test_nodeid'
E         - bla/test_nodeid.py::test_nodeid
E         ? ----
E         + test_nodeid.py::test_nodeid
...
    def test_ut(self):
        request = self._fixture_request
>       assert request.node.nodeid == 'test_nodeid.py::TestCase::test_ut'
E       AssertionError: assert 'bla/test_nod...Case::test_ut' == 'test_nodeid.p...Case::test_ut'
E         - bla/test_nodeid.py::TestCase::test_ut
E         ? ----
E         + test_nodeid.py::TestCase::test_ut

[blueyed]

Thanks for the reproducer - although I found it hard to replicate the out-of-tree case in tests.
I have something locally for this (hopefully will come to finish it tomorrow), but maybe you want to try #4352 on top of it already, which is relevant here.