Support @pytest.mark.usefixture in fixtures

[youtux]

• Target the master branch for bug fixes, documentation updates and trivial changes.
• Target the features branch for new features, improvements, and removals/deprecations.
• Include documentation when adding new features.
• Include new tests or update existing tests when applicable.
• Create a new changelog file in the changelog folder, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.
• Add yourself to AUTHORS in alphabetical order;

Followup from #3664 (comment).
I am trying to get the @pytest.mark.usefixture marker to work with fixtures as well.

[nicoddemus]

(Revisiting this)

The PR looks well written for a first draft, thanks! (Sorry for not commenting on it previously, missed the notification most likely).

---

I think once people notice that they can use @pytest.mark.usefixtures, they will probably also expect @pytest.mark.skipif to work too.

Is it a good idea to eventually support @pytest.mark.skipif (and the others) in fixtures? Perhaps the semantics should be "marks applied to fixtures mean that the marks are applied automatically to tests which use that fixture"? This would gain us all marks as part of fixtures. At first sight seems like a good idea, but I'm not sure.

@RonnyPfannschmidt what do you think?

Btw this discussion is out of scope for this PR, just me thinking aloud to get feedback.

[nicoddemus]

Hmmm just realized that this technically might be a challenge, because marks usually are applied during collection, and fixtures are lazily evaluated during test call...

[RonnyPfannschmidt]

its technically incredibly hard to correctly transfer markers from fixtures to nodes,
making one mark magically special is not going to be good in any way,

until we have a sound solution for markers on fixtures, its not acceptable to have some of them a little bit magically

a sound solution is hard to impossible right now as the fixture system has various features that make this more tricky (like replacing vs enhancing fixtures, dynamic fixture requests and a few more details) as well as the fact that the current internals of fixtures are rather frickly and fragile as the result of their development history

revisiting the original issue i have to note that while we improved some parts of marks, the parts that make it fundamentally a bad choice to support them on fixtures is still the same

[bluetech]

We've recently stopped using the features branch

(I've changed the base on my own now).

[nicoddemus]

revisiting the original issue i have to note that while we improved some parts of marks, the parts that make it fundamentally a bad choice to support them on fixtures is still the same

Agree completely. 👍

[youtux]

I soon realized after digging a little bit into pytest internals that indeed this would require a major architectural change, not just a small patch.
Closing this PR as I am not continuing this development.

[nicoddemus]

Thanks @youtux for trying! We appreciate it.

[jamt9000]

I think once people notice that they can use @pytest.mark.usefixtures, they will probably also expect @pytest.mark.skipif to work too.

Does the mechanism to use fixtures need to be a mark? How about defining @pytest.usefixtures that works for both fixtures and tests.