You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a long term plan: the end goal is to remove SopelWrapper by using contextvars in the Sopel class itself. The main issue is that removing the SopelWrapper may break the following cases:
type annotations using SopelWrapper will obviously fail, and mypy will complain
tests may need some adaptation to deal with a context specific bot instance
All these are perfectly acceptable for a major release, but shouldn't be introduced in a minor release. We should also ensure a period of deprecation, with warning in the documentation, and if possible in the code itself.
After a conversation on IRC, a rough plan is:
Sopel 8.0: warn in the documentation/release note/somewhere else that we are deprecating SopelWrapper bot: add deprecation notice to SopelWrapper #2521 (target version for removal unspecified for now, but probably 9.0)
Today, we use SopelWrapper to wrap an instance of Sopel and use it in plugin callable (the bot argument), and as a result:
we have an extra class to take care of
the documentation is split between 3 classes (the irc abstract class, Sopel, and SopelWrapper)
it uses magic method and magic behavior of Python related to attribute management, and we don't really need that
whenever we add/remove a fonction on Sopel we have to consider how it will or can be used with SopelWrapper, requiring more code, more tests, maybe more documentation, etc.
function signature need to know if they want a SopelWrapper object, a Sopel object, or both, which can be confusing
Notes
PR #2443 started the conversation around contextvars and removing SopelWrapper, but making such a drastic change in Sopel 8 is too much, hence this issue with a proper plan with a target version as Sopel 9.0.
The text was updated successfully, but these errors were encountered:
Summarizing short discussion from IRC: 8.0 is very long in the tooth now, it seems like we should at-most include a note in the docs about our intent to get rid of SopelWrapper Eventually™ for 8.0 with no code changes, and we can figure out the rest of the details when 8.0 is out the door
@dgw suggested 9.0 for release of the initial implementation of a contextvars replacement, which I think would push the removal of SopelWrapper to 10.0, but we can discuss more as we go.
@dgw suggested 9.0 for release of the initial implementation of a contextvars replacement, which I think would push the removal of SopelWrapper to 10.0, but we can discuss more as we go.
Thought I clarified in a follow-up line that I meant the switchover would happen in 9.0, with the implementation first shipping in 8.1, but maybe that got lost. x)
With the Issues preview, newly added sub-issues of this one can live in the intermediate milestone(s) like 8.1.0. This one can move to 9.0.0 so it doesn't clutter the 8.1 list.
Requested Feature
This is a long term plan: the end goal is to remove
SopelWrapper
by usingcontextvars
in theSopel
class itself. The main issue is that removing the SopelWrapper may break the following cases:isinstance
will breakSopelWrapper
will obviously fail, andmypy
will complainAll these are perfectly acceptable for a major release, but shouldn't be introduced in a minor release. We should also ensure a period of deprecation, with warning in the documentation, and if possible in the code itself.
After a conversation on IRC, a rough plan is:
SopelWrapper
bot: add deprecation notice to SopelWrapper #2521 (target version for removal unspecified for now, but probably 9.0)
SopelWrapper
behavior withcontextvars
#2526SopelWrapper
bySopel
in the code, and add code deprecation warning to prevent its future usage #2639SopelWrapper
in favor ofcontextvars
implementation #2527Problems Solved
Today, we use
SopelWrapper
to wrap an instance ofSopel
and use it in plugin callable (thebot
argument), and as a result:Sopel
, andSopelWrapper
)Sopel
we have to consider how it will or can be used withSopelWrapper
, requiring more code, more tests, maybe more documentation, etc.SopelWrapper
object, aSopel
object, or both, which can be confusingNotes
PR #2443 started the conversation around
contextvars
and removingSopelWrapper
, but making such a drastic change in Sopel 8 is too much, hence this issue with a proper plan with a target version as Sopel 9.0.The text was updated successfully, but these errors were encountered: