-
-
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
bot: new setup sequence #1597
bot: new setup sequence #1597
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.
I have a nitpick, as usual, but I like how much this simplifies the tests. 👍
What's wrong with you, Scrutinizer? |
Scrutinizer is just a flake. |
I had to rebase because of a conflict. :( |
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 think this is good to go, once rebased again to fix another merge conflict that crept in.
Once this goes in, I will take care of the follow-up in #1655.
Sopel's setup sequence is now: * setup logging * setup plugins * start Job Scheduler There are two major change: * Job Scheduler is now started after setup is complete * Logging setup is now called from `Sopel.setup` There is no good reason for the Job Scheduler to be started before the bot is ready to run, since jobs can be safely added or removed while it's not running. One may even consider that we should start the Job Sceduler once the bot is connected only - but that's for another day.
Again. |
At first, I had to rework the Job Scheduler in order to test how Sopel registers and unregisters plugins, which was annoying. But then, the solution wasn't perfect: I didn't like to have to manually stop the scheduler for testing purpose—which is time consuming and a bad thing when your test suite grow a bit (a lot at the moment). Aside from that, it also means that plugins where loaded, even if I didn't want them to be, or even needed to be. This is the first thing I fixed, by moving the call to
Sopel.setup()
outside ofSopel.__init__()
.Then, I realized: wait a minute... why do we setup plugins inside Sopel, but not logging? I couldn't find a good reason, so I moved that into Sopel's setup sequence.
Eventually, I thought: why do I even bother with the scheduler? Why do we need it started before anything else is even loaded? Answer is: we don't. We don't need that, and we don't have to start it whenever we instantiate
Sopel
.So here we go:
all wrapped nicely into the old but still relevant
Sopel.setup()
method.BONUS POINT: now the tests are slightly faster, and it's one step closer to facilitate reusability of
sopel.bot.Sopel
class for testing purpose (and everything else).