-
Notifications
You must be signed in to change notification settings - Fork 125
add specname option to hookimpl #251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@tlambert03 I will take a look at this week hopefully. Thanks for the PR too 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- implementation seems fine
- tests need a few small tweaks
- I'm not sure I know enough what this would enable / break, but seems mostly harmless to me 👍
This does not solve #218, as hooks are dealt, not hookspecs |
Yes, as mentioned in my comment above, I realize that though the syntax is the same as the original poster’s request in #218, the goal is likely not the same. So I will remove the “fixes” flag and you can keep that issue open if you’d like. However, this achieves what I was requesting, so do you have any thoughts/comments on the PR as it stands on its own, outside of the context of #218? |
its a nice addition, similar to whereas #218 was looking for something like |
Thanks @RonnyPfannschmidt! I will address the tests requests from @asottile and also curious to hear what @goodboy thinks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the comments made by @asottile, this looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @goodboy, any thoughts on this PR? one final question might be whether everyone is ok with the argument being named not directly related: we've decided to use pluggy as our plugin manager over at napari and we're all excited about it :) |
@tlambert03 so sorry. I'm ashamed the level of attention has been diverted away from
Oh, amazing. Hopefully we can make some good progress then moving forward 😸 |
not a problem! I know how these things go with open source. thanks for your time! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlambert03 this looks pretty good!
I left a few minor comments that I'd like to hear your opinion on.
One other outstanding would be to document or make an issue that we need to document this feature in an upcoming release.
Thanks again for the work!
It's nice to see some more eyes on the code base 🏄♂️
testing/test_hookcaller.py
Outdated
def he_myhook2(arg1): | ||
pass | ||
|
||
assert he_myhook1.example_impl.get("specname") is None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm not that it's a big deal but if hooks.py
:130 was removed this check would still pass.
Not sure if we need to be strict about the "normalization" entry in the opts dict
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah good point. that's probably an unnecessary test, since test_hookimpl
already pretty much makes sure that hookimpl parameters get added. Was just trying to follow the pattern. Should I just remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm not sure. If it's redundant I guess we don't need it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed it
also forgot to mention: I already created a PR #252 specifically for this. Couple things to discuss over there, but it's mostly set up. |
Hmm also code coverage target was missed eh? |
yeah, I'm looking at the codecov report now... I'm confused as well :/ relative to master, coverage should be the same if not slightly higher? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah looks great.
Only last thing would be pleasing the coverage target.
well, I guess it's working now. I did effectively nothing but trigger another push. I think it must have been comparing coverage to the previous commit and not to master? anyway. Thanks for the review. This looks ready to go. See you over in #252 ... |
thanks! |
Looks like pytest-dev#251 was forgotten in the changes for 1.0.0?
Include #251 in the release notes for 1.0.0
This also means that a single Python module can now register more than one implementation for the same hook, which is useful. https://til.simonwillison.net/pluggy/multiple-hooks-same-file |
This PR adds a
specname
option to@hookimpl
. Ifspecname
is provided, it will be used instead of the function name when matching this hook implementation to a hook specification during registration (allowing a plugin to register a hook implementation that was not named the same thing as the correspondinghookspec
).(Edited:) This is related to #218 (though likely different than that poster’s intentions)
Most of the interesting discussion is happening in #218 (@RonnyPfannschmidt voiced some opposition to the idea at one point), and you can see my use-case/rationale for wanting this feature in #218 (comment). But I figured since it's a small change, I would submit this so you could see exactly what I was proposing to make the discussion more concrete. Curious to hear your thoughts.
EDIT:
I should add that I'm not 100% sure this addresses the original poster's request in #218. They wanted a many-to-one registration, I simply want registration of non-matching function names.