[WIP] classmethod and class-scoped fixtures (#3778)

[nicoddemus]

Unfortunately I could not come up with a fix here.

The issue is that the fixture is declared as:

@classmethod
@pytest.fixture(...)
def setup(cls): ...

When we "unwrap" the fixture to get to the underlying setup function, we lose the classmethod decoration; we would have to get the original setup function and somehow reapply the @classmethod decorator in order to get the class object as cls when we call the function later. I don't see any way to do this in a general manner.

After thinking about this issue I'm afraid the conclusion is that we have to pull back the warning about calling fixture functions directly: its intention was good but this has caused many more problems than we expected to be worth the trouble at this point.

xref: #3778

[RonnyPfannschmidt]

should use !r

[RonnyPfannschmidt]

this is the order in-correctness i was talking about in #3780 - we structurally have to loose something as long as we wrap

[nicoddemus]

I gave this another go and I can't get it to work: classmethod objects are not really callable or have the attributes we expect functions to have (for example __name__ and __module__).

Even when I work around this by obtaining the __func__ object, I still cannot call @functools.wraps on it. Even when I work around that with a hack, it still blows on other parts of pytest because they expect callable objects later.

I'm nearly giving up here.

I see two solutions:

1. Revert the warning code about calling fixture functions directly: because we are no longer be able to use fixtures decorated with @classmethod this seems like a breaking change to me, although it was never documented and there were not tests for it.
2. Bite the bullet and document the fact that it was never supported and worked mostly by accident, suggesting a workaround instead: simply remove the @classmethod decorator and use cls = type(self) as one of the first lines in the fixture function instead.

What do you think @RonnyPfannschmidt? Because it worked mostly by accident and there's an easy workaround, I'm leaning towards 2).

[RonnyPfannschmidt]

class methods can be stroked via the descriptor protocol to return the actual function

>>> def func(cls):
...   pass
... 
>>> 
KeyboardInterrupt
>>> cm = classmethod(func)
>>> class Class(object): pass
... 
>>> cm
<classmethod object at 0x7f66468502b8>
>>> vars(cm)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: vars() argument must have __dict__ attribute
>>> cm.__get__(None, Class)
<bound method type.func of <class '__main__.Class'>>
>>> cm.__get__(None, Class).__func__
<function func at 0x7f664684a848>

[RonnyPfannschmidt]

so I'm leaning towards 3 - using the descriptor protocol (and encapsulating this bugger into something)

[nicoddemus]

Thanks for the code. I did obtain the underlying function with my testing earlier but ran in other errors in other parts, but I will give this another go then!

[nicoddemus]

Hi @RonnyPfannschmidt,

I gave this another go but still no success. 😞

In this example:

class Test:

    @classmethod
    @pytest.fixture(scope='class', autouse=True)
    def setup(cls):
        ...

What happens is:

1. @pytest.fixture is applied, and we wrap setup successfully with our object. At this point setup is a normal method, and @pytest.fixture has no way of knowing that @classmethod will be applied next.

2. @classmethod gets applied and bound to the class.

When we get to the point of creating the FixtureDef object during parsefactories, we try to "unwrap" the underlying function.

The function is obtained using getattr(Test, "setup") in parsefactories, so at this point we obtain a bound method to the Test class (not aclassmethod object) and even don't know about that fact anymore.

At this point we have these function layers:

function (returned by classmethod's .__get__, bound to the class)
|
|__ wrapped function (emits warning)
   |
   |__ setup

And here lies the problem as I see it: as we unwrap function to get to setup (in order to call it without emitting a warning), we lose the fact that function was applied to a classmethod in the first place, so setup ends up being called as a normal function.

Would you mind giving a go at this branch yourself? I'm nearly giving up, I'm afraid.

[RonnyPfannschmidt]

at earliest i can try next week

[nicoddemus]

Sure, sounds good, thanks!

[nicoddemus]

@RonnyPfannschmidt still want to try to fix this? I think this has very little use as we haven't seen more reports about this problem other than in #3778. I'm inclined to just close this and keep the existing behavior.

[nicoddemus]

Closing for the reasons stated in #3778 (comment).