Need to specially handle "historic" hooks

[ionelmc]

I want to use pytest_logwarning hook in a plugin but it seems that in 2.8 it want to be called with the .call_historic() api, which is not present in 2.7.

There's an assert not self.is_historic() in pluggy's _HookCaller for some reason.

Can anyone explain what's going on and why I need to care about this "history" aspect in the the call sites?

Currently I've settled to using config.warn instead, but that isn't without annoyances - in 2.8 it don't take fslocation argument. I'm doing a 'fslocation' in config.warn.func_code.co_varnames check 😩

[nicoddemus]

@ionelmc I'm afraid there's not a good solution at the moment... should we close this or perhaps move this question to pluggy's repo?

[ionelmc]

Hmmm... not really sure now. I think I only wanted to understand the internals a bit (iow: someone explain the "historic" things or point me in right direction).

[nicoddemus]

There's now some nice docs contributed by @tgoodlet, please take a look. I suspect they might answer your questions.

[RonnyPfannschmidt]

@ionelmc the introduction of historic hooks is something that happened in a unfortunate manner

adding on that there is my mistake on one of the hooks transforming it into a historic one to fix a bug

[ionelmc]

Now I get it. But why "call_historic" and not "deferred" or "deferred_call". So confusing :)

[nicoddemus]

Naming is hard 😁

[RonnyPfannschmidt]

@ionelmc a historic hook records call history. its not about defer or delay, its about keeping call history and invoking newly added implementations according to the call history

[ionelmc]

Yes, the name makes sense from implementor's perspective (as it accurately describes the most distinctive feature in the internals). However, from user's (or client's) perspective it don't make sense as the user don't care about internals. From the user's perspective the only distinct feature is that the call will succeed even if there is no handler registered for that hook. Agree? 😁