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

core: handle URL callbacks in coretasks #1510

Merged
merged 14 commits into from
Apr 24, 2019

Conversation

Exirel
Copy link
Contributor

@Exirel Exirel commented Mar 21, 2019

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:

  • never trigger URL Callbacks from the url built-in plugin
  • share the "find URL" feature into sopel.web (with unit tests for good measure)
  • trigger URL callbacks from a @url defined in coretasks

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.

@Exirel Exirel added High Priority Bugfix Generally, PRs that reference (and fix) one or more issue(s) labels Mar 21, 2019
@Exirel Exirel added this to the 7.0.0 milestone Mar 21, 2019
@Exirel Exirel self-assigned this Mar 21, 2019
@Exirel Exirel requested a review from dgw March 21, 2019 20:32
dgw
dgw previously requested changes Mar 22, 2019
Copy link
Member

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

sopel/coretasks.py Show resolved Hide resolved
sopel/modules/url.py Outdated Show resolved Hide resolved
test/test_web.py Show resolved Hide resolved
sopel/web.py Outdated Show resolved Hide resolved
dgw added a commit that referenced this pull request Mar 22, 2019
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)
@Exirel
Copy link
Contributor Author

Exirel commented Mar 23, 2019

@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. :)

@Exirel
Copy link
Contributor Author

Exirel commented Mar 23, 2019

multiple spaces before operator

Damn, I used flake8 sopel but forgot the test-suite. I was quite in a hurry this morning, my bad!

test/test_web.py Outdated Show resolved Hide resolved
@Exirel
Copy link
Contributor Author

Exirel commented Mar 23, 2019

What the hell is wrong with Python 2.7 this time???

Edit: that's what:

- if url[-1] is closer and url.count(opener) < url.count(closer):
+ if url[-1] == closer and url.count(opener) < url.count(closer):

Damn you, Py2.7. 😠 💢 💢 💢

@dgw
Copy link
Member

dgw commented Mar 23, 2019

Is that really an issue in py2? If so it probably needs to be applied on 6.6.x too :/

@Exirel
Copy link
Contributor Author

Exirel commented Mar 23, 2019

Is that really an issue in py2? If so it probably needs to be applied on 6.6.x too :/

Yes. 😭

@dgw
Copy link
Member

dgw commented Mar 24, 2019

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

kwaaak pushed a commit to kwaaak/sopel that referenced this pull request Mar 25, 2019
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)
@Exirel Exirel force-pushed the core-url-into-coretasks branch from 5df9a49 to c19ebeb Compare March 27, 2019 20:26
@Exirel
Copy link
Contributor Author

Exirel commented Mar 27, 2019

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

@Exirel
Copy link
Contributor Author

Exirel commented Mar 27, 2019

Py2.7 & Py3.4 tests pass with the exception of the ip test, so I think we are good. :)

@dgw
Copy link
Member

dgw commented Mar 27, 2019

I'll get Travis to re-run the tests after #1523 makes it into master. Did you want to do any squashing on this branch at all, @Exirel, or just leave all the commits in? (I'm fine with having the full evolution, just curious if you planned to squash down the little fixups like for flake8 failures and py2.7 compat etc.)

@Exirel Exirel force-pushed the core-url-into-coretasks branch from 7431ef4 to 349f4e0 Compare March 27, 2019 22:37
@dgw dgw dismissed their stale review March 27, 2019 23:29

Stale review, and I need a "dismissed" webhook payload to examine for sopel-github dev reasons

@dgw dgw self-requested a review March 27, 2019 23:29
Copy link
Member

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

sopel/coretasks.py Outdated Show resolved Hide resolved
sopel/modules/url.py Outdated Show resolved Hide resolved
sopel/modules/url.py Outdated Show resolved Hide resolved
sopel/web.py Show resolved Hide resolved
sopel/web.py Outdated Show resolved Hide resolved
test/test_web.py Outdated Show resolved Hide resolved
@dgw
Copy link
Member

dgw commented Apr 15, 2019

Shall we get back on this horse now that you have a laptop again, @Exirel? 😁

@Exirel
Copy link
Contributor Author

Exirel commented Apr 15, 2019

Oh yes, right. I'll resume working on that very soon.

Copy link
Member

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

sopel/config/core_section.py Outdated Show resolved Hide resolved
sopel/config/core_section.py Outdated Show resolved Hide resolved
sopel/config/core_section.py Outdated Show resolved Hide resolved
sopel/web.py Show resolved Hide resolved
@dgw dgw removed the Needs Review label Apr 20, 2019
@Exirel Exirel force-pushed the core-url-into-coretasks branch 2 times, most recently from 56b8523 to 3317c0b Compare April 20, 2019 06:37
@Exirel
Copy link
Contributor Author

Exirel commented Apr 20, 2019

@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. :)

@Exirel
Copy link
Contributor Author

Exirel commented Apr 20, 2019

I added more information in the sopel.module.url decorator's docstring, with a link to auto_url_schemes and to bot.register_url_callback.

Note that I've tested the example added in this docstring to make sure it worked as intented.

Copy link
Member

@dgw dgw left a 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). 😛

sopel/config/core_section.py Outdated Show resolved Hide resolved
sopel/config/core_section.py Outdated Show resolved Hide resolved
@Exirel
Copy link
Contributor Author

Exirel commented Apr 21, 2019

@dgw ready for a last review to 🚢

Copy link
Member

@dgw dgw left a comment

Choose a reason for hiding this comment

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

:shipit: (optionally after squashing any fixup commits you'd like to clean from the history) 🎉

@Exirel Exirel force-pushed the core-url-into-coretasks branch from 0b9ec40 to b3ac099 Compare April 23, 2019 21:33
@Exirel
Copy link
Contributor Author

Exirel commented Apr 23, 2019

Fixup commits squashed, ready to 🚢

@dgw dgw merged commit 6e5ded2 into sopel-irc:master Apr 24, 2019
kwaaak pushed a commit to kwaaak/sopel that referenced this pull request May 13, 2019
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)
@Exirel Exirel deleted the core-url-into-coretasks branch September 5, 2019 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bugfix Generally, PRs that reference (and fix) one or more issue(s) High Priority
Projects
None yet
2 participants