-
-
Notifications
You must be signed in to change notification settings - Fork 402
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
core: handle URL callbacks in coretasks #1510
Conversation
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.
Some little notes here and there, but I have a bigger question.
If search_urls
(almost) always gets used wrapped in list()
, why does it not just return a list in the first place? That's probably more intuitive from an API standpoint than the yield
/generator pattern. Even excluding the tests, more uses of search_urls
want a list than not.
There are ways to keep the generator-style algorithm and still return a list, FWIW.
A change that should have been made in #1413, but was overlooked. This proves why having more than one developer review changes is useful. @Exirel indirectly found this omission during an overhaul of Sopel's URL-handling for version 7. See #1510 (comment)
@dgw I think I fixed most of the issue, you're welcome for the second round, and once everything's fine I'll rebase/squash accordingly. :) |
Damn, I used |
What the hell is wrong with Python 2.7 this time??? Edit: that's what:
Damn you, Py2.7. 😠 💢 💢 💢 |
Is that really an issue in py2? If so it probably needs to be applied on 6.6.x too :/ |
Yes. 😭 |
Well. You'd think I would have caught that myself, given that my primary Sopel instance still runs in py2 and I'm therefore invested in maintaining compatibility… Added this bugfix to my todo list for 6.6.x. :/ |
A change that should have been made in sopel-irc#1413, but was overlooked. This proves why having more than one developer review changes is useful. @Exirel indirectly found this omission during an overhaul of Sopel's URL-handling for version 7. See sopel-irc#1510 (comment)
5df9a49
to
c19ebeb
Compare
@dgw From my point of view, everything's fine. Yet it appears that Travis isn't happy with an unrelated test (it has something to do with Google stuff). So if you want to merge, it's ready for the last review. |
Py2.7 & Py3.4 tests pass with the exception of the |
I'll get Travis to re-run the tests after #1523 makes it into |
7431ef4
to
349f4e0
Compare
Stale review, and I need a "dismissed" webhook payload to examine for sopel-github dev reasons
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.
I know you're planning to change some more stuff in here, @Exirel, but I noticed a thing or two that jumped out at me and then decided to just do a review because why not? 😁 Admittedly I skimmed over some things that I reviewed before, so hopefully I didn't miss anything because I thought I already looked at it but didn't.
Thought about suggesting to put the URL callback handler in bot.py
instead of coretasks.py
, but… nah. It doesn't belong there.
Shall we get back on this horse now that you have a laptop again, @Exirel? 😁 |
Oh yes, right. I'll resume working on that very soon. |
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.
I had to rush this review, but I wanted to make sure it got done. The rest of my evening could extend way past the point when I'd be any use at code review.
My only real question is why the url
module (plugin? we should talk about whether to move sopel.module
decorators to sopel.plugin
in 8 or 9+) still uses @module.rule
to look for URLs, when it could instead use the URL callbacks. This is to prevent triggering on URLs that are handled by any other modules, right?
Seems sad that we (you) go to all this work building a nice URL-callback system that actually works, only for it to be unusable in the module literally named "url". 🤣 But we talked about this before. It's that damn threading problem—modules can't block each other from running, so instead url
has to check if any other handler exists for the link it's about to process and stop itself.
Actually, would it be excessively messy for url
to use a URL callback just like everyone else, but abort early if any other callbacks match the URL it gets? (Probably, but I have to ask.)
56b8523
to
3317c0b
Compare
@dgw I manually tested that everything worked fine. Now I'll try to write some documentation. This can be done in this PR, or in a separated one. As you wish. :) |
I added more information in the Note that I've tested the example added in this docstring to make sure it worked as intented. |
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.
Two itsy bitsy docstring tweaks, and I think we're there!
I'm going to be lazy and not test this very exhaustively, because I trust your testing regimen better than my own (and you wrote thorough unit tests, too). 😛
@dgw ready for a last review to 🚢 |
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.
(optionally after squashing any fixup commits you'd like to clean from the history) 🎉
* take advantage of generator function * generate tinyurl for valid URL only * store **valid** last seen and processed URL, not the last found
0b9ec40
to
b3ac099
Compare
Fixup commits squashed, ready to 🚢 |
A change that should have been made in sopel-irc#1413, but was overlooked. This proves why having more than one developer review changes is useful. @Exirel indirectly found this omission during an overhaul of Sopel's URL-handling for version 7. See sopel-irc#1510 (comment)
This fix #1489 - at last!
PR #1508 added a new interface for plugin maintainers, that would help us work with URL callbacks. In this PR, I:
url
built-in pluginsopel.web
(with unit tests for good measure)@url
defined incoretasks
This way, one may disable the
url
plugin, and the bot won't auto-title URLs. However, other plugins will still be able to define and use URL Callbacks.Plugins that use
@rule
and define their own callback will still work, and that won't trigger callbacks.By the way, this should fix sopel-irc/sopel-github#13 too as soon as the github plugin uses
@url
instead of@rule
.