why adding conftest.py "adds" to the sys.path ?

[david-fliguer-ws]

Hi,

I was having some issues importing a module that is on a folder in an "upper" level than the .py of my test (In general I know that a lot of importing issues in python are related to the sys.path) so I printed the sys.path and effectively I don't see the folder that contains the module that I wanted to import (Despite inside pycharm it gives me autocomplete), however once I create an empty conftest.py in the upper level of my project then I don't have an import error and I can see that having the conftest.py "added" values to the sys.path.

Can someone explain how conftest.py affects the sys.path values ?

Thanks,

David

[nicoddemus]

Hi @david-fliguer-ws,

In short, pytest needs to import the conftest.py, and in order to do so it needs to append the directory that contains the conftest.py to sys.path.

[david-fliguer-ws]

Thanks for the fast answer !!!

That means than whenever I have a conftest.py file in the uppest level of my project then I can freely make imports in any .py file that I have there and in lower levels ? (No need to "manipulate" the sys.path or stuff like:

from ....\xxx import)

Relying on the conftest.py (Usually it won't be empty and I will use it for fixture reasons) is it a good "approach" to solve import issues ?

[nicoddemus]

Exactly, but is not considered a good approach to that problem because it relies on a (necessary) side-effect of how pytest imports conftest.py files.

It is suggested instead to use virtual environments and "editable" installs.

[wimglenn]

Avoid conftest.py in the project root, if you can. I usually put a tests/conftest.py.

Related: src-based project structures https://hynek.me/articles/testing-packaging/

[blueyed]

@nicoddemus

In short, pytest needs to import the conftest.py, and in order to do so it needs to append the directory that contains the conftest.py to sys.path.

But that could be undone also after importing, couldn't it?

[RonnyPfannschmidt]

@blueyed currently, that would break quite some interesting usages (deferred imports in hooks for example)

[blueyed]

@RonnyPfannschmidt
I see - just wasn't sure if I misses something else.

It is clear that it would break backward-compatibility (but that's what this issue is about basically).

As for deferred imports in hooks, those could also get wrapped by changing sys.path then temporarily I guess.

[nicoddemus]

@blueyed my feeling is that could generate much more problems than it is worth.