Pathlib relative_to issue on python 3.13+

[dlegaultbbry]

Describe the bug
pathlib relative_to fails with pyfakefs in testing. This only happens on python 3.13 and 3.14. 3.12 works fine with the test.

This code runs fine in production.

Note that the bug doesn't manifest itself if you do not have the dataclass and the sub-function called. This was the simplest reproducer I could come up with to showcase the error.

The bug still happens with pyfakefs 6.1.0

How To Reproduce

from dataclasses import dataclass
from pyfakefs.fake_filesystem import FakeFilesystem
from pathlib import Path

@dataclass
class Options:
    rootdir: Path

FAKE_OPTIONS = Options(
    rootdir=Path('/root'),
)

def something(utpath: Path, options: Options) -> None:
    print(utpath)
    print(options.rootdir)
    rel_path = utpath.relative_to(options.rootdir)


def test_pyfakefs_bug(fs: FakeFilesystem):

    utpath = Path('/root/src/unittests')
    fs.create_dir(utpath)

    something(utpath, FAKE_OPTIONS)

fs = <pyfakefs.fake_filesystem.FakeFilesystem object at 0x75afad170c20>

    def test_pyfakefs_bug(fs: FakeFilesystem):
    
        utpath = Path('/root/src/unittests')
        fs.create_dir(utpath)
    
>       something(utpath, FAKE_OPTIONS)

/code/tests/pyfakefs_bug_test.py:25: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/code/tests/pyfakefs_bug_test.py:17: in something
    rel_path = utpath.relative_to(options.rootdir)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = PosixPath('/root/src/unittests'), other = PosixPath('/root')

    def relative_to(self, other, *, walk_up=False):
        """Return the relative path to another path identified by the passed
        arguments.  If the operation is not possible (because this is not
        related to the other path), raise ValueError.
    
        The *walk_up* parameter controls whether `..` may be used to resolve
        the path.
        """
        if not hasattr(other, 'with_segments'):
            other = self.with_segments(other)
        for step, path in enumerate(chain([other], other.parents)):
            if path == self or path in self.parents:
                break
            elif not walk_up:
>               raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
E               ValueError: '/root/src/unittests' is not in the subpath of '/root'

Your environment

Linux-6.8.0-87-generic-x86_64-with-glibc2.39
Python 3.14.2 (main, Dec  9 2025, 19:03:28) [Clang 21.1.4 ]
pyfakefs 6.0.0
pytest 9.0.2

[mrbean-bremen]

Thanks for the report!
The issue is related to this known problem - the comparison of real and fake Path objects fails in this case. The message: "'/root/src/unittests' is not in the subpath of '/root'" is related to '/root/src/unittests' being a fake path and '/root' a real path, created outside of the class.
Unfortunately, while the problem disappeared in Python 3.11 and 3.12 (as mentioned in the documentation), in reappeared in Python 3.13 (pathlib is often heavily restructured between Python releases, which makes it more difficult to handle for pyfakefs).

I will see if I can find a possibility to make this work again - probably need to re-implement relative_to, and maybe more methods.

[dlegaultbbry]

Thank you for the docs reference. I never found that entry with all the search power (and LLMs) I could muster.

Now at least I know how the problem manifests and how to work around it in the meantime.

[mrbean-bremen]

Sorry - forgot to follow up on this. I had tried to make this work, but this would only fix half of it - I can get the fake path work with the real one, but not vice verse. I had the same problem before, and decided to leave it as is (as a limitation), as long as I haven't got a better idea how to handle this.

[dlegaultbbry]

Fine with me. Now that we know what is causing it, we can generally work around it in our test code.

[mrbean-bremen]

I have thought about this a bit more, but haven't found a sensible way to change this. This is the same limitation that unittest.mock has, with the same possible workarounds, so I'm moving this to discussions.