Extend pytest capabilities to support fastapi Depends-style fixtures

[ZeeD]

What's the problem this feature will solve?

I am a long-time unittest user, and I'm now starting a new project and starting using pytest.
I am struggling to use the fixtures in my project.

While the basic case (the fixture function defined alongside the test function in the same module) is easy to understand and apply, I'm trying to move some (session-scoped) fixture outside of the tests modules and in a dedicated package.

But then I've fought with the (missing) fixture discovery capabilities of pytest, and the only solution I've found is to create also a conftest.py in the root of my tests folder with a bunch of from myfixtures.myfixtureXXX import * to let the tool discover the fixtures available.

Moreover it seems odd to me that the "request" of a fixture is made by the name of the function / test parameter, as I see this error prone, and limiting.

Describe the solution you'd like

I would like to suggest a more explicit (and direct) way to execute a fixture, that would be "roughly speaking" like the experience of using fastapi's dependency injection system Depends

So I propose a new pytest.provider(fixture: Callable) function exposed from pytest that would allow the users to have a following solution

"my_code.py"

def foo(bar: str):
  ...

"my_fixture.py"

import pytest
@pytest.fixture()
def get_bar():
  return 'my fake bar'

"test_my_code.py"

from my_code import foo
from my_fixture import get_bar
import pytest
from typing import Annotated

def test_foo(bar: Annotated[str, pytest.provider(get_bar)]):
  assert foo(bar) == ...

this mechanism makes totally explicit the relation between the fixture execution and usage, and also relies on totally "normal" imports of functions, instead of the magic of "conftest.py" discovery

Ideally this could be implemented as a plugin, but I'm not sure about it

Alternative Solutions

The current solution is based on too much magic

Additional context

[The-Compiler]

Duplicate of #3834