deprecate pytest.config

[dmtucker]

Could someone please explain the difference of pytest.config.getoption vs request.config.getoption and whether one should be preferred? Both seem to work, but I am unable to find any documentation/history on them.

[pytestbot]

GitMate.io thinks the contributors most likely able to help are @nicoddemus, and @RonnyPfannschmidt.

[The-Compiler]

request.config and pytest.config give you the same config object. request.config is preferred, as pytest.config is kind of a cumbersome global. I actually thought it was deprecated, but off-hand I can't find any documentation on it.

[RonnyPfannschmidt]

reminds me that we should replace pytest.config with something that prints warnings about removal in 4.x

[dmtucker]

@The-Compiler @RonnyPfannschmidt Excellent, thank you for the clarification.
We can close this unless it'd be useful for tracking the addition of a removal warning.

[asmodehn]

Let me point you here to the documentation as a reason for using this feature : https://docs.pytest.org/en/reorganize-docs/example/simple.html#control-skipping-of-tests-according-to-command-line-option

How would I define a decorator to use an option if I need to access the config object ? As far as I understand request is not accessible in that context.

[RonnyPfannschmidt]

@asmodehn string based conditions have access to the config

also there is the option of implementing a more complete handling of the markers/deselection

[asottile]

via #4498

[alcm-b]

@The-Compiler, @RonnyPfannschmidt, could you provide some more details on what was wrong with pytest.config, which lead to this decision? After it got deprecated, I find that now we have to pass config variable all around our utility classes.

request.config is preferred, as pytest.config is kind of a cumbersome global

Having a global pytest.config is in fact useful and it is also to the point: there is just a single entity of config, which is also read only (hopefully), so it's inherently global.

[RonnyPfannschmidt]

Its fundamentaly broken and cant be fixed

[alcm-b]

Oh, ok.

[nicoddemus]

Having a global pytest.config is in fact useful and it is also to the point: there is just a single entity of config, which is also read only (hopefully), so it's inherently global.

Indeed, but just to add to the response, it has some edge cases regarding config initialization which may cause surprising results and makes the current internal initialization code cumbersome.

If you are using it in some utility classes which are not created from a fixture (which would provide an easy access to request.config), consider saving the global yourself during pytest_configure:

# conftest.py
def pytest_configure(config):
    MyUtilitiClass.pytestconfig = config

By the time pytest_configure gets called, the config object is fully initialized and ready to be used, which is not always the case for pytest.config.

(Btw I recommend the approach above to keep existing code working, new code should probably consider accessing this from a fixture).

[Sup3rGeo]

Hi guys, is there any way of doing the following without a global pytest.config variable?

• conftest.py
• tests
  • conftest.py
  • test_one.py

conftest.py:

def pytest_addoption(parser):
    parser.addoption("--choice", action="store")

def pytest_configure(config):
    some_global_variable = config.getoption('--choice')

tests\conftest.py:

if some_global_variable == "A":
   @pytest.fixture
   def fixture(dependency_A):
       print("A")
else:
   @pytest.fixture
   def fixture(dependency_B):
        print("B")

tests\test_one.py:

def test_one(fixture):
    """ Here we have a fixture dependent on a command line option """
    pass

Basically I would like to control which fixtures go inside tests\conftest.py based on a pytest command line option.

Basically the addoption executes first, I can pass the --choice option, but then tests\conftest.py gets imported before pytest_configure() in the toplevel conftest runs, which of course gives me an error that some_global_variable is not defined.

The workaround I have so far is basically using an environment variable instead of a pytest option, which is not as nice.

[tucked]

@Sup3rGeo How about this (in tests\conftest.py)?

    @pytest.fixture
    def fixture(request):
        choice = request.config.getoption('--choice')
        if choice == "A":
            dependency_A = request.getfixturevalue('dependency_A')
            print("A")
        elif choice == "B":
            dependency_B = request.getfixturevalue('dependency_B')
            print("B")

[Sup3rGeo]

@tucked thanks for the suggestion but unfortunately it wouldn't work in my case as they really need to be distinct fixture functions (I am actually importing them from different modules).

However in the meantime I found a solution - I implemented pytest_addoption and pytest_load_initial_conftest in a local plugin with a setuptools entrypoint, so I know they are executed before any conftest.py files are imported.

The drawback is that now in my test repository I have a setup.py and have to do pip install (-e) .. It would be nice if there could be some sort of local plugin that could have the same behaviour without the need of using setuptools. I might open a new issue for that.

[RonnyPfannschmidt]

@Sup3rGeo

# untested and fast typed
class PluginForA:
   @pytest.fixture
   def fixture(dependency_a):
    ...

class PluginForB:
   @pytest.fixture
   def fixture(dependency_B):
    ...

def pytest_configure(config):
  if ...
    plug= PluginForA()
  else:
    plug = PluginForB()
  config.pluginmanager.register(plug)

[Sup3rGeo]

@RonnyPfannschmidt perfect, I actually had thought about the plugin approach in the meantime and it in fact is the answer in this case!