Skip to content
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

add specname option to hookimpl #251

Merged
merged 11 commits into from
Feb 5, 2020

Conversation

tlambert03
Copy link
Contributor

@tlambert03 tlambert03 commented Jan 27, 2020

This PR adds a specname option to @hookimpl. If specname 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 corresponding hookspec).
(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.

@goodboy
Copy link
Contributor

goodboy commented Jan 27, 2020

@tlambert03 I will take a look at this week hopefully.
Hopefully some others will pipe in with opinions as well.

Thanks for the PR too 👍

Copy link
Member

@asottile asottile left a 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 👍

testing/test_hookcaller.py Show resolved Hide resolved
testing/test_hookcaller.py Outdated Show resolved Hide resolved
@RonnyPfannschmidt
Copy link
Member

This does not solve #218, as hooks are dealt, not hookspecs

@tlambert03
Copy link
Contributor Author

does not solve #218

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?

@RonnyPfannschmidt
Copy link
Member

its a nice addition, similar to fixture(name="foo") the hookimpl(name="foo")

whereas #218 was looking for something like hookspec(name=re.compile("foo_(P<pluginname>.*)")

@tlambert03
Copy link
Contributor Author

Thanks @RonnyPfannschmidt! I will address the tests requests from @asottile and also curious to hear what @goodboy thinks.

Copy link
Member

@nicoddemus nicoddemus left a 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.

Copy link
Member

@asottile asottile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tlambert03
Copy link
Contributor Author

tlambert03 commented Feb 4, 2020

hi @goodboy, any thoughts on this PR?

one final question might be whether everyone is ok with the argument being named specname instead of simply name or hookname... let me know if you have thoughts on that.

not directly related: we've decided to use pluggy as our plugin manager over at napari and we're all excited about it :)

@goodboy
Copy link
Contributor

goodboy commented Feb 4, 2020

@tlambert03 so sorry. I'm ashamed the level of attention has been diverted away from pluggy over the past year..
I will do my best to look now.

we've decided to use pluggy as our plugin manager over at napari and we're all excited about it :)

Oh, amazing. Hopefully we can make some good progress then moving forward 😸

@tlambert03
Copy link
Contributor Author

not a problem! I know how these things go with open source. thanks for your time!

Copy link
Contributor

@goodboy goodboy left a 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 🏄‍♂️

def he_myhook2(arg1):
pass

assert he_myhook1.example_impl.get("specname") is None
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed it

src/pluggy/manager.py Outdated Show resolved Hide resolved
testing/test_hookcaller.py Show resolved Hide resolved
@tlambert03
Copy link
Contributor Author

One other outstanding would be to document or make an issue that we need to document this feature in an upcoming release.

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.

@goodboy
Copy link
Contributor

goodboy commented Feb 5, 2020

Hmm also code coverage target was missed eh?
I wonder if that was because of the redundant check you removed?

@tlambert03
Copy link
Contributor Author

Hmm also code coverage target was missed eh?
I wonder if that was because of the redundant check you removed?

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?

testing/test_hookcaller.py Outdated Show resolved Hide resolved
Copy link
Contributor

@goodboy goodboy left a 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.

@tlambert03
Copy link
Contributor Author

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 ...

@goodboy goodboy merged commit 6e8b6d4 into pytest-dev:master Feb 5, 2020
@tlambert03 tlambert03 deleted the hookimpl-specname branch February 5, 2020 19:28
@tlambert03
Copy link
Contributor Author

thanks!

cjolowicz added a commit to cjolowicz/pluggy that referenced this pull request Sep 1, 2021
Looks like pytest-dev#251 was forgotten in the changes for 1.0.0?
bluetech added a commit that referenced this pull request Oct 1, 2021
Include #251 in the release notes for 1.0.0
simonw added a commit to simonw/til that referenced this pull request Dec 20, 2021
@simonw
Copy link
Contributor

simonw commented Dec 20, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants