`SopelWrapper` helpers break down for server messages

[dgw]

Plugin devs taking their first steps beyond PRIVMSG-based triggers may soon find their expectations violated. For messages that a user didn't send (i.e. server messages, raw numerics) it's easy to not notice that trigger.sender, trigger.nick, and friends behave differently.

I've thought about adding explicit checks for the recipient being None or empty (pushed to no-empty-say-recipient branch, no PR yet, still thinking about it), but this issue runs deeper. I don't want to just rush in with a band-aid solution for one or two symptoms.

Accidentally relying on the default destination or trigger.sender generally results in an exception traceback, since get_sendable_message() can't handle None as input. Not ideal, but should be obvious in plugin testing and easily fixed. Could be made more obvious by the aforementioned checks (draft no-empty-say-recipient branch does more than just that).

Accidentally relying on trigger.nick is more insidious: The server will probably just drop the message to an invalid nick. (trigger.nick often ends up being a server hostname for numeric events.) That's harder for new devs to debug.

I have no more concrete ideas yet. I just want us to start thinking about broader changes to how triggers work—raising an exception for attributes like sender and nick that can't be derived for that event type. Maybe even passing a Sopel for bot instead of SopelWrapper for events without the context that SW is meant to wrap.

(At the very least, we can start by improving docs about the affected methods and properties/attrs. The never-ending battle…)

[clawdney]

Hi! I'm interested in helping with this. Could you share more context about the use case?

[dgw]

This particular issue isn't open for contributions just yet. The action items aren't anywhere near concrete enough. As the labels say, it's for long-term planning. Perhaps we'll get around to it for the next major release, or perhaps not.