Fixtures without name matching magic

[shoyer]

I've been happily using pytest for several projects for the past few years.

There's one part about pytest that I still struggle to get behind: The way that fixtures magically match argument names to fixtures -- and apparently I'm not alone in this feeling. I would much rather declare dependencies explicitly in some way using code. I know this would be more verbose, but that's a tradeoff I'm happy to make.

Is it possible to do this in some way with pytest today? If not, would you be open to adding an optional feature for this?

I was thinking perhaps something like the following, using an example adapted from the docs:

import pytest

@pytest.fixture
def smtp_connection():
    import smtplib
    return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)

@pytest.use_fixture(smtp_connection)
def test_ehlo(connection):
    response, msg = connection.ehlo()
    assert response == 250
    assert 0 # for demo purposes

[nicoddemus]

Hi @shoyer,

If you don't like the way fixtures are automatically injected, you can be more explicit in a way very similar to the example you provided:

import pytest

@pytest.fixture
def smtp_connection():
    import smtplib
    return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)

@pytest.mark.usefixtures("stmp_connection")
def test_ehlo(smtp_connection):
    response, msg = connection.ehlo()
    assert response == 250
    assert 0 # for demo purposes

[shoyer]

@nicoddemus that's explicit about using a fixture, but it's still using a string to refer to a name variable. Is it possible to do something like that while referencing smtp_connection as a Python object -- preferably with a different, non-conflicting argument name?

[nicoddemus]

Probably you can do something like this:

import pytest

def use_fixture(fixfunc):
    def inner(f):
        return pytest.mark.usefixtures(fixfunc.__name__)(f)
    return inner

@pytest.fixture
def fix():
    return 1

@use_fixture(fix)
def test(fix):
    assert fix == 1

But you still need to use the same name in the argument as the fixture, plus you will need to explicitly import the fixture function into the test module in case it is not defined there, and that is not really recommended because it messes with the internal caching of the fixtures.

that's explicit about using a fixture, but it's still using a string to refer to a name variable.

What is the problem with that in your opinion? That's very explicit IMHO: @pytest.mark.usefixtures("fix") explicitly declares that the test function uses a fixture "fix", and that is passed as argument name.

preferably with a different, non-conflicting argument name?

Not sure what is the reason for that, can you explain?

[shoyer]

But you still need to use the same name in the argument as the fixture, plus you will need to explicitly import the fixture function into the test module in case it is not defined there, and that is not really recommended because it messes with the internal caching of the fixtures.

Indeed, but also using fixfunc.__name__ for lookup is a good example of exactly what I was trying to avoid here.

What is the problem with that in your opinion? That's very explicit IMHO: @pytest.mark.usefixtures("fix") explicitly declares that the test function uses a fixture "fix", and that is passed as argument name.

I want to use Python's normal rules for resolving symbols (i.e., standard variable lookup), and I want to keep introspection to the bare minimum needed to run tests. I know pytest uses magic to rewrite assert and decide which tests to run, but in general I like my Python code (even tests) to follow the normal rules of Python code.

Referencing functions by string name instead of object breaks normal code introspection tools (e.g., lint), which can't recognize misspelled names if there's no variable reference. So if I write stmp_connection instead of smtp_connection, nothing catches that mistake until I actually run my tests.

(In my opinion, one of the best things about Python is that dependencies are explicit, unless you use the discouraged import *.)

preferably with a different, non-conflicting argument name?

Not sure what is the reason for that, can you explain?

As one simple example, if you run this example through pylint, you get the following warning:

W0621: Redefining name 'smtp_connection' from outer scope (line 7) (redefined-outer-name)

At Google, we actually strictly enforce running pylint on all Python code. If I wanted to disable this message, I would need to write a comment # pylint: disable=redefined-outer-name.

Now, pylint is known for being overly-aggressive in some cases, but I do think that in general it's best not mask variable names from outer scopes. There's basically no reason why this is ever necessary if not using pytest, and if done unintentionally, this can easily lead to bugs.

---

Another example of what doing this explicitly could look like, with keyword arguments:

@pytest.mark.usefixtures(conn=smtp_connection)
def test_ehlo(conn):
    ...

Using a fixture imported from another module also becomes very straightforward, e.g.,

@pytest.mark.usefixtures(conn=other_module.smtp_connection)
def test_ehlo(conn):
    ...

[nicoddemus]

Hi @shoyer sorry for taking so long to get back at this.

I'm not sure it has a place in the core though, as it would lead to a different way of doing things, and is solving not really an existing problem but a personal preference which is shared by some people but not by the majority of pytest users (at least that's what I think, no hard data here).

But all you are proposing is probably possible to write as a plugin. I suggest you give this a try (be sure to post here if you need help) and see how that feels in real code.

What do you think?

[RonnyPfannschmidt]

personally i have been thinking about such a mechanism as well, i just dont have the time to work on even a base for it

[burnpanck]

Let me add to this that the name-matching does lead to real-world problems: I just spent an hour trying to get my pytest-sanic tests to working, not realising that it's test_client fixture clashes with the test_client fixture of pytest-aiohttp.

[tuukkamustonen]

This would be really nice. I hate dropping # pylint: disable=redefined-outer-name lines to my test files because pylint will nag about every test with a fixture otherwise.

The original suggestion by @shoyer looks good enough, imo. Anyway, here are some extra thoughts:

# not supported by python(?):

def test_ehlo(@pytest.inject(smtp_connection) connection):
    ...

# dunno if this would be doable, either:

@pytest.fixture
class SmtpConnection:
    def __call__(self):
        import smtplib
        return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)

@pytest.inject
def test_ehlo(conn: SmtpConnection):
    ...

[nicoddemus]

This would be really nice. I hate dropping # pylint: disable=redefined-outer-name lines to my test files because pylint will nag about every test with a fixture otherwise.

Just to mention that fixtures have a name parameter to avoid this problem:

@pytest.fixture(name='smtp_connection')
def smtp_connection_():
    ...

def test_ehlo(smtp_connection):
    ...

[tuukkamustonen]

Oh, that's a workaround I could use. Good to know.

Though the benefit in being able to do something like what I suggested above would be that when you (have to) import fixtures, they are then actually referenced in the tests file, and your import will not get marked as unused (and removed if you auto-organize imports). Sure I could:

from foo import my_fixture

PYTEST_IMPORTS = my_fixture

But then PYTEST_IMPORTS will be marked as unused :P (or would importing even work together with name=?)

[countvajhula]

I'll register my support for this issue as well. When users first see tests written in pytest, it is mystifying how the arguments to these functions get populated. At least having the option to be explicit about it in a robust way would be nice.

Another possible benefit is the ability to give a different name to the same fixture in different tests. Or maybe more specifically, the ability to give the same name to different fixtures in different tests. Not sure if this is already possible, but with an explicit mechanism like the one @shoyer is talking about, it could look something like this:

Let's say we have these fixtures for an application that processes log files (this is a barebones example just to illustrate the point):

@pytest.fixture
def simple_logfile():
    return ("2019-08-16 10:35:05 connection established\n"
             "2019-08-16 11:07:16 connection dropped\n")

@pytest.fixture
def empty_logfile():
    return ""

With the current behavior, we could write tests like this:

def test_read_logfile(simple_logfile):
    result = read_logfile(simple_logfile)
    assert result == True

def test_read_empty_logfile(empty_logfile):
    result = read_logfile(empty_logfile)
    assert result == True

In the proposed behavior, it could look like this:

@pytest.mark.usefixtures(logfile=simple_logfile)
def test_read_logfile(logfile):
    result = read_logfile(logfile)
    assert result == True

@pytest.mark.usefixtures(logfile=empty_logfile)
def test_read_empty_logfile(logfile):
    result = read_logfile(logfile)
    assert result == True

The explicit approach allows the generic aspects of the test code to remain generic -- in this example, the test only cares about reading a logfile and asserting that it works. The fact that we have selected this file to be an empty one to test an edge case is already captured in the name of the function, and avoiding the need for different variable names seems desirable since the code is the same.

In fact, doing it this way gives us yet another advantage -- the possibility of parametrizing over fixtures using pytest.mark.parametrize. For instance, the proposed behavior could now look like this:

@pytest.mark.parametrize(
    "logfile", (simple_logfile, empty_logfile),
)
def test_read_logfile(logfile):
    result = read_logfile(logfile)
    assert result == True

... which covers both tests in a single parameterized test.

It looks like there is currently already a way to parametrize fixtures themselves. That's a great feature as well, but I think the ability to parameterize the test rather than the fixture is a different thing which could complement the current functionality and lend additional flexibility.

[jadkik]

I think the ability to parameterize the test rather than the fixture is a different thing which could complement the current functionality and lend additional flexibility.

FYI there is already a way to do this in a nice-ish way:

import pytest


@pytest.fixture
def simple_logfile():
    return 'simple_logfile contents'


@pytest.fixture
def empty_logfile():
    return 'empty_logfile contents'


@pytest.fixture(name='logfile')
def dynamic_fixture(request):
    return request.getfixturevalue(request.param)


@pytest.mark.parametrize('logfile', ['simple_logfile', 'empty_logfile'], indirect=True)
def test_something(logfile):
    print()
    print('test_something', repr(logfile))

Downside being that you can't do indirect parameterization of simple_logfile from test_something, and it doesn't show up when you run pytest with --setup-plan (it does when you do --setup-only though.

I can still see the benefit in this proposal, though: if usefixtures accepts keyword arguments with names or actual fixture functions, it could be a change that doesn't break the current behaviour.

[ms-lolo]

Just wanted to drop my support for this request as well. The current fixtures functionality acts as a global registry of magical variable names and globals are confusing and error prone for the reasons already outlined a few times above. When I'm creating new fixtures I should not need to try and think of a globally unique name for it as long as I've implemented it in my globally unique package name.

It's a little disappointing to try and convince folks on the team to write maintainable/testable code and then run into the testing framework itself not following software engineering best practices. We only need to write this code once but we have to read it, understand it, and maintain it for years. We can afford to type a few extra lines of code to make sure it works and is immediately clear to anyone that might run into it in the future.

[nicoddemus]

Hi @ms-lolo,

It's a little disappointing to try and convince folks on the team to write maintainable/testable code and then run into the testing framework itself not following software engineering best practices. We only need to write this code once but we have to read it, understand it, and maintain it for years. We can afford to type a few extra lines of code to make sure it works and is immediately clear to anyone that might run into it in the future.

I sympathize with that sentiment, but personally I think the issue boils down more to introducing another way to use fixtures, which might lead to even more confusion when the classic way and this new way proposed here are mixed.

As was stated before, I believe it is possible to implement a different mechanism as a plugin, but adding this directly to the core without first seeing it being used in the wild might not be the best approach.

[shoyer]

I sympathize with that sentiment, but personally I think the issue boils down more to introducing another way to use fixtures, which might lead to even more confusion when the classic way and this new way proposed here are mixed.

If we agree that an explicit API is better, we might consider deprecating the current global name matching entirely, and eventually only supporting the new way (or at least suggesting it as the preferred option for new code).

[ms-lolo]

Totally understand wanting to avoid having multiple ways of doing this. And using a plugin to demonstrate a cleaner approach sounds like a great idea that I'm going to try and find some time to investigate, although I have no experience with the pytest internals, so any guidance would be appreciated!

I'm not sure it has a place in the core though, as it would lead to a different way of doing things, and is solving not really an existing problem but a personal preference which is shared by some people but not by the majority of pytest users (at least that's what I think, no hard data here).

I was mostly leaving a comment to add a data point about this comment :) I disagree with the statement that this is a personal preference but we don't need to go down that rabbit hole without even a proof of concept alternative to compare to.

[countvajhula]

@jadkik Nice, though another downside is that, judging by your example, we'd need to write a wrapping dynamic fixture for every set of fixtures we might want to parametrize over. And since we would be creating this abstraction behind yet another global name, this does not escape the namespace issues that @ms-lolo brings up. By separating the fixture definition from its name, we gain the ability to abstract over any set of fixtures behind a lexically-scoped name in each test, without having to pre-designate (via a wrapper function like dynamic_fixture) which ones those are.

[The-Compiler]

FWIW maybe we could turn to ward for inspiration here. It uses default argument values to make fixtures more explicit (and namespaced) without having much more boilerplate:

from ward import fixture, test

@fixture
def user():
    return User(id=1, name="sam")

@test("fetch_user_by_id should return the expected User object")
def _(expected_user=user):
    fetched_user = fetch_user_by_id(id=expected_user.id)
    assert fetched_user == expected_user

I don't particularly like the @test decorator/naming thingy myself, but having namespaced fixtures which can be imported and used by specifying them as argument value seems pretty nice to me.

It's still "name matching magic", but at least a bit more explicit and, most importantly, namespaced.

Of course the million dollar question is how to implement this with the already quite complex fixture code, especially in a way that's backwards compatible. So far I haven't had the time (or mind-space) to see if it'd even be realistic at all.

[RonnyPfannschmidt]

anything in the domain of adoption/modifying the mechanisms in which fixture lookup works is something for after we de-cruft and de-tangle it

from past experience its pretty much doomed before we simplify/expliticify it

my take is that we can't hope to do better until we make it reasonably sane to choose the dependency injection system and to integrate a external one with pytest fixtures as a base

personally i really want to enable better lookup, but that comes after de-tangleing what grew due to the history that started with the pytest_funcarg__somename hooks that wouldn't cache

[graingert]

now that pytest is Python3.5+ only, using an Annotations based DI is possible: https://fastapi.tiangolo.com/tutorial/dependencies/

[nicoddemus]

@shoyer

If we agree that an explicit API is better, we might consider deprecating the current global name matching entirely

That's an idea, and probably the way to go for certain features, but not for fixture IMO: it would break every pytest suite out there which uses fixtures. This kind of breakage would kill the project IMO.

@ms-lolo

Totally understand wanting to avoid having multiple ways of doing this. And using a plugin to demonstrate a cleaner approach sounds like a great idea that I'm going to try and find some time to investigate, although I have no experience with the pytest internals, so any guidance would be appreciated!

It depends on the mechanism actually... there are some proposals in this thread, but importing and using the actual names in the test function definition, bypassing the current global lookup, might not be possible through a simple plugin, I'm afraid.

@RonnyPfannschmidt

my take is that we can't hope to do better until we make it reasonably sane to choose the dependency injection system and to integrate a external one with pytest fixtures as a base

Indeed, but it seems this would take many hours of someone dedicated to this task to tackle.

now that pytest is Python3.5+ only, using an Annotations based DI is possible: fastapi.tiangolo.com/tutorial/dependencies

Indeed, and that's similar to what ward does, as @The-Compiler commented.

---

My take overall:

• Enabling more explicit fixture lookup would be great
• Currently the pytest internals don't allow for that
• Backward compatibility is a hard requirement

So this is a very complicated issue. 😓

[rtaycher]

It's pretty barebones but people might find it useful to reference fixtures by reference.

https://github.com/rtaycher/pytest-fixture-ref
pip install git+https://github.com/rtaycher/pytest-fixture-ref.git
people should feel free to make suggestions or PRs or suggest name changes
I'll try to publish it on pypi before the weekend

pip install git+https://github.com/rtaycher/pytest-fixture-ref.git

from pytest_fixture_ref import make_test_with_fixtures

@make_test_with_fixtures()
def test_bar1(f1=fix_w_yield1, f2=fix_w_yield2, tmp=tmp_path):
    print("test_bar")
    print(f'{tmp}')
    assert tmp.exists()


@make_test_with_fixtures(f1=fix_w_yield1, f2=fix_w_yield2, tmp=tmp_path)
def test_bar2(f1, f2, tmp):
    print("test_bar")
    print(f'{tmp}')
    assert tmp.exists()

[rtaycher]

@nicoddemus is there a common way to import pytest plugins?
from _pytest.tmpdir import tmp_path works for tmp_path but I couldn't find some of the others.
What about fixtures in various pytest plugins?

[nicoddemus]

There is no standard for that, each plugin decides which API to expose; so in your case from pytest_fixture_ref import make_test_with_fixtures is fine. 👍

Btw, if you have Twitter, feel free to tweet about that project and I'll be glad to retweet (also we can ask the pytest-dev official twitter to retweet too).

[ms-lolo]

@rtaycher can I suggest splitting up the two versions of fixtures into their own decorators? I'm opposed to the version that inspects the functions' default values and I think it would be useful to have that decision be clearer when we write our tests. A lot of development on large code bases happens by copying nearby code and having them as separate decorators makes it clearer that, in this code base, we chose style A over style B.

[rtaycher]

@rtaycher can I suggest splitting up the two versions of fixtures into their own decorators? I'm opposed to the version that inspects the functions' default values and I think it would be useful to have that decision be clearer when we write our tests. A lot of development on large code bases happens by copying nearby code and having them as separate decorators makes it clearer that, in this code base, we chose style A over style B.

@ms-lolo Could you open an issue with some suggested names? I tend to bikeshed maybe @fixtures_from_default_value and @fixtures_from_ref? Both sound not quite right to me

[rtaycher]

@nicoddemus https://twitter.com/rtaycher1987/status/1593199919892156418
@ms-lolo I split them into using_fixtures_from_defaults/using_fixtures_from_kwargs since I realized this would work not just for tests but for fixtures that take other fixtures

sorry it took so long. Figuring out the CI/publish setup for the boilerplate I used took a while(hit a number of odd library issues, plus the autochangelog is really annoying)

It's now on pypi so people can just use pip install pytest-fixture-ref

[nicoddemus]

Nice, thanks @rtaycher!

I also recommend that suggestions/requests to be made in https://github.com/rtaycher/pytest-fixture-ref/issues instead of in this thread, as that is the appropriate place. 👍

[YakovL]

A couple of notes:

1. This also hurts DX if one uses Pylance as it also complains like Pylint; it also lacks completions

2. The workaround

   @pytest.fixture(name='session_manager')
   def get_session_manager():
       return GameSessionsManager()
   
   def test_create_session(session_manager: GameSessionsManager):
       ...
   

   is fragile: since the GameSessionsManager type is casted to the argument, once implementation of get_session_manager is changed (say, returns GameSessionsManager | None), things can get broken.

[ZeeD]

@adriangb your proposal sounded very promising
Did the work continued ? Is there some branch of pytest that could be used?

[adriangb]

I got bogged down in internal implementations of pytest and never got to finishing it. It mostly worked, and worked well, but there was bugs I just couldn't fix. I don't think I'll have time to do it myself.

[RonnyPfannschmidt]

can you provide a open draft pr for reeference - it may enable us to put focus on the bugs to enable the rest

[adriangb]

I think this was my WIP branch: https://github.com/adriangb/di/tree/pytest. But given that it was last touched 3 years ago I don't know the state of it. To be clear I'm not saying there were bugs in pytest, more so that I just didn't understand how things were supposed to work internally, especially when it came to the async plugins.

[tristan]

I have thrown together a quick plugin that allows fixtures to be resolved using Annotated[...] rather than their full name.

e.g.

from typing import Annotated
from pytest_annotated import Fixture

class SomeThing:
    pass

@pytest.fixture
async def somefixture(someotherfixture) -> SomeThing:
    return SomeThing()

async def test_thing(st: Annotated[SomeThing, Fixture(somefixture)]):
    assert isinstance(st, SomeThing)

you can find it here: https://github.com/tristan/pytest-annotated and here: https://pypi.org/project/pytest-annotated/

Unfortunately, I feel it requires the use of too many _private parts of pytest, so I'm a bit scared of the maintenance burden it will require to keep it up to date. Would be super happy to have someone more familiar with the internals of pytest to make suggestions for making it less brittle .

[RonnyPfannschmidt]

that one is a funky little hack, we ought too figure if we can enable lookup by name, type and annotated type in future

[millerdev]

https://pypi.org/project/pytest-unmagic/ is a pytest plugin that implements fixtures with normal import semantics.

Fixtures are applied to tests or other fixtures with a @use decorator. Alternately, a fixture can be called without arguments to get its value inside a test or other fixture function.

[RonnyPfannschmidt]

@millerdev at first glance pytest-unmagic is a complete deception - using magic globals unrelated to the actual fixtures instead of actual values passed - i strongly discourage anyone from using it - it does the opposite of its name

[millerdev]

@RonnyPfannschmidt Fixtures are global objects. Pytest registers them in an opaque hierarchical namespace, and effectively does a global lookup each time a fixture is requested. The magic that this plugin eliminates is function-scoped local names magically invoking global fixtures. Granted, the active request reference is not the nicest feature. Hopefully we can work together to improve it?

The active request reference allows unmagic.fixture to work with pytest features such as --setup-show and --fixtures. While implemented as a module-level singleton by default, it does provide a mechanism for thread-local or other custom scoping. In most cases this will be unnecessary.

I have a development branch where the global active request reference has been removed, but it has trade-offs. The implementation is more complicated, and it is impossible to use fixtures in the context of unittest.TestCase. I didn't release it (yet) because the test suite that pytest-unmagic was originally intended for uses unittest-style tests extensively, and allowing fixtures to be used there is a big win.

For now—in the very spirit of pytest fixtures—practicality beats purity.

[RonnyPfannschmidt]

This explanation seems to discard important distinction between concepts like registries, discovery, references,actions at a distance and some more

As far as I'm concerned it's much worse than what we have right now

I'm happy to work towards more explicit control of the registries as well as sane lookup

But injection of dependencies at a distance instead of parameters is absolutely off the table, that's completely unacceptable

[nicoddemus]

My 2 cents on the plugin -- I agree with @RonnyPfannschmidt overall about the design, however I'm also happy that @millerdev did an experiment to try things out (it is his project after all!).

But regardless I wanted to share my opinions on some points (I'm not speaking for all maintainers or for the pytest project at all, but only how I see this topic):

• The existence of an external plugin that does "fixtures without name matching" does not automatically imply endorsement from the pytest project, much less that it will be incorporated at some point.

• I think pytest should never stray from the current fixture mechanism, or even support both, even if there are people clamoring for that to be the case -- besides being an controversial topic¹, there's backward compatibility, and having to teach/learn multiple ways of doing the same thing.

• I do think, however, that we should improve pytest so plugins can change how fixtures are handled, allowing plugins to implement whatever mechanism one prefers over the current name matching in core pytest.

Footnotes

1. I think the current fixture mechanism in pytest is absolutely fine, IMO lots of frameworks implement things that seem like "magic" at first glance, for example dataclasses "magically" injecting methods, SQL/Django columns "magically" talking to a DB based on how attributes are declared... if you squint hard enough many framework features can be shrugged off (or even bad mouthed) as magic. ↩

[burnpanck]

@nicoddemus: Clarke's third law states "any sufficiently advanced technology is indistinguishable from magic". That is not at all a bad thing. It just means that as soon as a mechanism is not obvious how it works, it appears as if it were magic. Once you understand how things work, its not magic anymore, but just a great power to wield. And with great power, comes great responsibility.

IMHO, what is wrong with the current fixture mechanism is the single global namespace shared among all participants in a given test session. Thus, this particular great power is hard to guide to its intended target. Rather than a surgical laser beam, these fixtures behave like a virus; once you unleash them, they go everywhere, hitting both intended and unintended targets. It appears magic to the many users, because once that virus arrives at your site (intended or not), you don't see where it comes from. This applies both to humans and to tools (type checkers). More importantly, the design makes it impossible to reason about the area of effect within any subscope, because you always need to know the full testing session before you can start figuring out where fixtures may come from or go to.

This is very different from the magic methods in dataclasses or the various forms of automatic schema validation and column creation in ORMs. Its true that it can appear equally magic to someone who doesn't understand the mechanism, but once you do understand, a) the rules are simple (as in the current pytest fixtures) and b) the amount of inputs you need to consider to apply them are reasonably bounded (unlike in the current pytest fixtures).

[nicoddemus]

Thanks @burnpanck for the detailed reasoning, you make good points.

Regardless, all my previous points still stand: backward compatibility, more than one way to do the same thing, etc, and those do not change regardless of the discussion about what constitutes a magical behavior or not.

But again, this is all from my POV, I don't know if other core maintainers feel otherwise and think it is OK to add an additional way to use fixtures to core pytest.

[millerdev]

I do think, however, that we should improve pytest so plugins can change how fixtures are handled, allowing plugins to implement whatever mechanism one prefers over the current name matching in core pytest.

Yay! 🎉 This would be wonderful.

what is wrong with the current fixture mechanism is the single global namespace shared among all participants

This is precisely why I think pytest-unmagic is an improvement on pytest magic fixture parameters. "Unmagic" fixtures are always explicitly referenced, and do not occupy a single shared global namespace. The question "where is the code for that?" can be answered without any knowledge of pytest fixture name resolution.

The part that @RonnyPfannschmidt reacted so strongly to (I think) is the active request reference, which is an implementation detail that allows the plugin to bind fixture setup and teardown to the appropriate scope and to retrieve the value from pytest's internal fixture cache. It is easy to reason about the active request within the context of any given test or fixture, so that single global reference does not seem as problematic as a shared global namespace for all fixtures.

Maybe "unmagic" is a bit of a misnomer. The plugin moves the "magic" part from fixture name resolution, which everyone using fixtures is confronted with, to an implementation detail where most people don't need to know much if anything about it. You might need to know if you're running tests in parallel within a single Python interpreter, but that is not a problem I tried to solve in v1.0.

[septatrix]

I think the annotation way which was already raised there is a very good idea. It is not that magical (pretty much just using typing.get_type_hints(metafunc.definition.function) + a fixture registry) and has already reached significant adoption by projects like SQLAlchemy and FastAPI. The implementation by @tristan https://github.com/tristan/pytest-annotated already looks quite good. It would be great to either open the private APIs which he is currently using or consider incorporating it into core pytest.

Regarding two ways to archive the same thing I also do not really have concerns. There are already other aspects where two approaches are used in pytest. The one that directly comes to my mind is import-mode which has gained importlib and is now recommended.

[adriangb]

+1 for the approach pytest-annotated seems to be taking!

[RonnyPfannschmidt]

pytest-annotated looks like a good prototype

However we are not in a position to open the apis it's using

But I'm more than happy with working towards integrating types with fixture lookup