Warn if both pytest.ini (.pytest.ini) and pyproject.toml with pytest ops exist

[ludwick]

What's the problem this feature will solve?

I was going absolutely batty about why my pyproject.toml pytest options, particularly filterwarnings settings weren't actually filtering some warnings. The document on the capture warnings mentions both options to configure and since I had ours in pyproject.toml, that's what I was tweaking values in.

Eventually I put breakpoints in the pytest code for handling warnings (in _pytest/warnings.py) and realized that the pytest config had NONE of our tool.pytest.ini_options available and was using some other random set. Wondering if I had something misformatted in pyproject.toml, I checked the configuration docs and realized that pytest.ini would result in pyproject.toml settings being entirely ignored. Removing it fixed my filter warnings issues.

Describe the solution you'd like

A warning when pytest starts up and detects multiple sources of configuration exists as this is almost certainly not intentional. Especially as more people put everything in their pyproject.toml, this "obvious" rake is easy to step on. Note that there is output like this at pytest startup:

configfile: pytest.ini

But given how much things can print to the terminal when running tests, it can easily run off screen especially if you add prints and other things to debug and be easily missed. Possibly just changing this to this output when the ignored config is detected:

configfile: pytest.ini (WARNING: ignoring pytest config in pyproject.toml!)

Alternative Solutions

Other possible mitigations:

• This github issue so folks searching here (as I did) will be prompted to check for this (in retrospect) very obvious thing
• A reminder in the capture warnings documentation that pytest.ini will "win" over pyproject.toml.

Additional context

Yes, I missed multiple indicators that this misconfiguration existed!

[augustebaum]

I have been bitten by this before. Personally I would expect pytest.ini to override pyproject.toml options, without unsetting non-overridden ones; in any case a warning would be helpful.