I'm looking to figure out the best way to deprecate a hook we have provided to end users and might be implemented in some plugins already. In a more general sense, I want to be able to add my own metadata to spec and impl opts and have ways of acting on that inside pluggy itself.
For the record, I have considered registering a try-first implementation or hook wrapper that raises the deprecation warning. And that's the easy answer, but I'd like to be able to include this information in documentation of the spec itself (potentially through a sphinx plugin or something similar) so inserting it into the spec_opts seemed like the wiser thing to do. From there, I'd also like to be able to act on it in the hook caller.
However, I found this difficult mostly because of that static calls to _HookCaller that required copying large amounts of code into a subclass. Some of it could be cut down -- for example _HookCaller.__call__ doesn't need to be overridden only _HookCaller._hookexec needs to be intercepted and wrapped.
I understand that I'm poking at things that are probably not intended to be poked at, or at least weren't considered open to being poked at. But is there potential for opening them up to poking?
I'm looking to figure out the best way to deprecate a hook we have provided to end users and might be implemented in some plugins already. In a more general sense, I want to be able to add my own metadata to spec and impl opts and have ways of acting on that inside pluggy itself.
For the record, I have considered registering a try-first implementation or hook wrapper that raises the deprecation warning. And that's the easy answer, but I'd like to be able to include this information in documentation of the spec itself (potentially through a sphinx plugin or something similar) so inserting it into the
spec_optsseemed like the wiser thing to do. From there, I'd also like to be able to act on it in the hook caller.However, I found this difficult mostly because of that static calls to
_HookCallerthat required copying large amounts of code into a subclass. Some of it could be cut down -- for example_HookCaller.__call__doesn't need to be overridden only_HookCaller._hookexecneeds to be intercepted and wrapped.I understand that I'm poking at things that are probably not intended to be poked at, or at least weren't considered open to being poked at. But is there potential for opening them up to poking?