Conversation
| same name as the function being decorated by ``@hookimpl`` (e.g. | ||
| ``setup_project`` in the example above). | ||
|
|
||
| *new in version 0.13.2:* |
There was a problem hiding this comment.
obviously, took a guess at this... feel free to directly edit this (or any other part of this PR).
goodboy
left a comment
goodboy
left a comment
There was a problem hiding this comment.
@tlambert03 thanks again for the great work!
I added a few comments. Feel free to push back if I'm being too pedantic 😉
|
|
||
| .. _specname: | ||
|
|
||
| Hook implementation naming |
There was a problem hiding this comment.
Hmm how about Hook spec selection by name.
That or linking?
edit: or Hookspec name matching as you mentioned below?
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| During plugin :ref:`registration <registration>`, hook implementations are | ||
| matched to a hook :ref:`specifications <specs>` in the *host* program with the |
There was a problem hiding this comment.
matched to a hook :ref:specifications <specs> if provided in the host..
There was a problem hiding this comment.
to make the sentence read a bit better, I broke into two sentences, restated that there is no string 1-1 requirement, and linked to "enforcing spec validation".
| *new in version 0.13.2:* | ||
|
|
||
| To override the default behavior, a *hookimpl* may also be matched to a | ||
| *hookspec* in the ``host program`` with a non-matching name by using the |
| To override the default behavior, a *hookimpl* may also be matched to a | ||
| *hookspec* in the ``host program`` with a non-matching name by using the | ||
| ``specname`` option. Continuing the example above, the *hookimpl* function | ||
| does not need to be named ``setup_project``: |
There was a problem hiding this comment.
does not need to be named setup_project but if specname="setup_project" it will be matched and checked against the setup_project hookspec.
these all work for me! thanks, added (made a slight modification to the if provided sentence... but I think it's the same sentiment). you ok with it stating new in version 0.13.2:? is that a safe assumption? (and any guesstimate about your release cycle?) |
|
test failed due to HTTP error. closing and reopening to trigger new build. |
3 participants
assuming you choose to merge #251, this PR adds a section to your docs about hook implementation naming and the
specnameoption.